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
I support this, but recommend that the extensions for obsolete (and potentially insecure) file types ".doc, .xls, .ppt, .rtf" also not be available by default.
Images:
> 'bmp' => 'image/bmp'
> 'ico' => 'image/x-icon'
> Files are quite large
Ridiculous.
The PmWiki core is designed to run on a potato. Things have changed in 26 years!
computers are faster, bandwidth is faster, everything is better and faster.
I dont care how large the files are. In 2026, Giant Video is not bloat. It’s a standard.
I use lots of bmp and ico files. I do not want to convert them to another format.
I think ico files are ususally for 32x32 pixel icon images.
How can you consider that large? good grief!
--gnuzoo
They are disabled by default under this proposal.
They are easily re-enabled in config.php and will still work, PmWiki being so flexible and all that.
I like this proposal because PmWiki OOTB meets my needs as as a webmaster, and I do not have to first disable infrequently used, or potentially insecure, file and image types.
PS I find PmWiki runs better on a kumara.
I dont want to have to re-enable them in config.php.
Leave them alone. What a crazy idea. Why do you even care
about bmp and ico files? Are you programming your computer
with paper punch cards?
Lets require that ANYTHING you do in PmWiki will require you enable it in
your config.php. You will also have to create a new CSS file just for that too.
And also write some javascript and install a PHP program into your cookbook directory,
then make a really long complex regex for it. From now on you will be required to do this
to type the letter 'a' and do the same exact thing to type the letter b, ... and the
numbers and every character, and every action and URL for eternity. It seem crazy
but every time you want to do ANYTHING you have to do these things.
EVERYTHING is a recipe that requires editing the config.php file and jumping
through a f****** hoop! AAAAAAAARRRRRRRRRGGGGGGGGGHHHHHHHH!
--gnuzoo
This is not respectful or helpful, and does not encourage me to provide FREE assistance to you. NOBODY is asking you to enable anything. You CAN use an older version. Or use the new version WITHOUT enabling options in config.php. Both upgrading PmWiki and enabling optional features are completely VOLUNTARY. You COULD appreciate that we work hard to provide options to enable, disable, and revert. Petko
> not respectful
Sorry, no disrespect intended. Do you recognize the irony?
It is frustrating that it appears some PmWiki people want to maintain
the same exact model from 25 year ago. Things change a LOT.
I want to see PmWiki change. Size of a bmp is 99.99999 percent not
an issue. Even less so for ico. Bandwidth is no longer a limiting factor.
BTW, I used to program on paper punch cards myself.
I hated it when the reader would jam up.
Fortran, Assembly, RPG II, COBOL. That was a long time ago.
--gnuzoo
I disagree with your claims, and there is no need to continue this point further. See my previous reply for 2 optional workarounds. Petko