01509: Deprecate rarely used upload extensions from the core
Description: Pm agreed that updating the default set of file extensions makes sense and suggested to do deprecation cycle where we can warn that file extensions are scheduled to be disabled by default before we actually disable them.
Current upload types (PmWiki-2.3.35):
Category | Extensions |
---|---|
image files | gif, jpg, jpeg, png, bmp, ico, wbmp, wmf, xcf, webp, avif |
audio | mp3, au, wav, ogg, flac, opus, m4a |
video | ogv, mp4, webm, mpg, mpeg, mov, qt, avi, mkv |
archives | zip, 7z, gz, tgz, rpm, hqx, sit |
office | pdf, odt, ods, odp, odg, doc, docx, ppt, pptx, xls, xlsx, mdb, rtf, csv |
executables | exe |
Adobe | psd, ps, ai, eps |
text files | txt, tex, dvi |
misc | kml, kmz |
I am considering deprecating the following upload extensions from the default allow-list for 2.3.36, and removing them in early 2025. Any of these extensions can be re-enabled in config.php if they are required. Existing uploads with these extensions will not be affected.
Images:
- 'bmp' => 'image/bmp'
- 'ico' => 'image/x-icon'
- Files are quite large, compressed lossless PNG or lossy JPEG/WebP are better depending on the content.
- 'wbmp'=> 'image/vnd.wap.wbmp'
- 'psd' => 'image/vnd.adobe.photoshop'
- 'xcf' => 'image/x-xcf'
- 'wmf' => 'image/wmf'
- 'apng' => 'image/apng'
- Not embedded in-page, or older, or only professionals share them.
Audio:
- 'au' => 'audio/basic'
- 'wav' => 'audio/x-wav'
- Older audio formats, current lossy or lossless compressed formats are better supported by browsers; normally only professionals share them.
Video:
- '3gp' => 'video/3gpp'
- 'avi' => 'video/x-msvideo'
- 'mpg' => 'video/mpeg'
- 'mpeg' => 'video/mpeg'
- 'mov' => 'video/quicktime'
- 'qt' => 'video/quicktime'
- Older formats, or not widely supported for embedding, or mostly professionals use them. Currently, mp4, webm, ogg are more efficient and widely supported for online video.
- 'vtt' => 'text/vtt'
- Video subtitles format is recent and if the server is not aware of it, it may try to autodetect the type. If a rogue HTML file with a VTT extension is uploaded on such a server, this may open a XSS vulnerability.
Publishing:
- 'ps' => 'application/postscript'
- 'ai' => 'application/postscript'
- 'eps' => 'application/postscript'
- 'tex' => 'application/x-tex'
- 'dvi' => 'application/x-dvi'
- These are older or platform-specific formats, currently PDF has taken over. Professionals who need to share these formats on their wiki can re-enable them in config.php.
Executables, Applications:
- 'exe' => 'application/octet-stream'
- 'rpm' => 'application/x-rpm'
- These can be re-enabled in config.php if needed.
Other:
- 'hqx' => 'application/mac-binhex40'
- 'sit' => 'application/x-stuffit'
- Older archive formats, virtually unused today
- 'mdb' => 'application/x-msaccess'
- Older database files, superseded by modern database servers and cloud computing.
- 'kml' => 'application/vnd.google-earth.kml+xml'
- 'kmz' => 'application/vnd.google-earth.kmz'
- Like VTT, this format is recent and if the server is not aware of it, it may try to autodetect the type. If a rogue HTML file with a KML extension is uploaded on such a server, this may open a XSS vulnerability. I realize these are used on 2 wikis, notably with Cookbook:Ape, but admins could re-enable them in config.php.
Let me know if you see good reasons to keep some of these, or to remove other extensions. --Petko
I'm going to assume that you'll just comment these out to make it easier for people like me out them back. Thanks ~Astro
No, you should never edit core files. You can always add your changes to config.php, and they will be used by PmWiki. This will be documented like on ReleaseNotes#v2335. --Petko
What is the benefit to this? This strikes me as disabling functionality for no real reason. I would just leave it alone if I were you. --SCG 2024-07-17
The benefit is to not allow unneeded and unexpected uploads to your wiki. I've added the rationale for each formats in dark blue color. Administrators who need and expect these formats can very easily reenable them. --Petko