Last modified: 2012-10-10 19:53:28 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 11142 - blacklist extension handling is broken
blacklist extension handling is broken
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
1.20.x
All All
: Low minor with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch
: 11529 13088 15004 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-31 22:26 UTC by SJ
Modified: 2012-10-10 19:53 UTC (History)
18 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Patch so that the api will give more useful information when uploading a blocked file type (2.29 KB, patch)
2011-10-13 23:00 UTC, Tomer A.
Details
A patch to fix the uploadwizrd (850 bytes, patch)
2011-10-13 23:03 UTC, Tomer A.
Details
A patch to fix the uploadwizrd (1.56 KB, application/x-httpd-php)
2011-10-13 23:06 UTC, Tomer A.
Details
A patch to fix the uploadwizrd (863 bytes, patch)
2011-10-13 23:08 UTC, Tomer A.
Details

Description SJ 2007-08-31 22:26:03 UTC
The global file-extension blacklist uses two different strings to identify the real extension of the file (the last .xxx at the end of the filename) and the extension that throws an error (it inexplicably checks for all 'extension' substrings in the filename, so that hello.py.zip.txt will have py, txt, and zip all checked for a blacklist match).  

This should perhaps be two bugs; the most immediate is that the error thrown on the above file could be ".txt is not an allowed extension" when it is actually choking on ".py"

The second is that I can't see why extensions other than the final one should be blacklisted in the first place.
Comment 1 Brion Vibber 2007-09-04 20:55:56 UTC
Multiple extensions are checked on upload because the web server also checks multiple extensions when it's determining the type of a file to serve out.

For instance, on an Apache server where the '.ogg' extension hasn't been configured (common on 1.3.x), a file 'Foo.php.ogg' may instead be recognized as a PHP script due to its recognized .php extension, and executed through the PHP module.

That has obvious security implications. :)


We should indeed be reporting the matching extension rather than the last one, though.
Comment 2 Brion Vibber 2007-10-02 14:59:45 UTC
*** Bug 11529 has been marked as a duplicate of this bug. ***
Comment 3 Brion Vibber 2008-02-21 05:19:05 UTC
*** Bug 13088 has been marked as a duplicate of this bug. ***
Comment 4 Brion Vibber 2008-08-01 16:25:07 UTC
*** Bug 15004 has been marked as a duplicate of this bug. ***
Comment 5 Dan Collins 2011-07-13 20:07:31 UTC

*** This bug has been marked as a duplicate of bug 28609 ***
Comment 6 Antoine "hashar" Musso (WMF) 2011-07-19 10:43:25 UTC
Reopening. Does not seem to be a dupe of bug 28609
Comment 7 Tomer A. 2011-10-13 13:18:21 UTC
It seems that someone has already fixed this bug. 

On an attempt to upload a file called bug 11142.txt.png; he.wiki and en.wiki alerts that:

".txt" is not a permitted file type. Permitted file types are png, gif, jpg, jpeg, xcf, pdf, mid, ogg, ogv, svg, djvu, tiff, tif, oga. 

However, on commons I get an error message saying: "This type of file is banned". Hence, this is a problem with the upload wizard.
Comment 8 Tomer A. 2011-10-13 18:25:06 UTC
After some more research it seems that this isn't necessarily a bug in the upload wizard rather than a bug in the API. 

It looks like someone had fixed this in the upload form but hadn't fixed this in the api.
Comment 9 Tomer A. 2011-10-13 23:00:33 UTC
Created attachment 9231 [details]
Patch so that the api will give more useful information when uploading a blocked file type

As it turns out SpecialUpload.php and ApiUpload.php are going in two different ways. 

Assuming that the user is trying to upload a blacklisted filetype, SpecialUpload will throw the error message in 'filetype-banned-type'  while ApiUpload.php will throw the error message in 'filetype-banned'. 'filetype-banned' is less informative as it doesn't tell the user what was the extension that was blocked and does not support plural text. 

I could not make the API uploader work with the plural template and I suspect that it's not up to it anyway. In such a case there are few ways we can deal with it:
1. Assume singular text and show the most inner (innerest?) file extension that was blocked.
2. Assume plural text and implode all extensions that were blocked.
3. Assume plural text and show all the file types that are not allowed on that Wiki.

I chose option #3. If someone could show me how to identify plural text in the API uploader it should be fairly easy to output only the file extensions that were blocked in this file.
Comment 10 Tomer A. 2011-10-13 23:03:57 UTC
Created attachment 9232 [details]
A patch to fix the uploadwizrd

This patch adds the relevant to the uploadwizard so that it'll give some informative message to the user when a file is blocked due to blacklisted extension.
Comment 11 Tomer A. 2011-10-13 23:06:21 UTC
Created attachment 9233 [details]
A patch to fix the uploadwizrd

A patch to fix the uploadwizrd

This patch adds the relevant to the uploadwizard so that it'll give some
informative message to the user when a file is blocked due to blacklisted
extension.
Comment 12 Tomer A. 2011-10-13 23:08:02 UTC
Created attachment 9234 [details]
A patch to fix the uploadwizrd

This patch adds the relevant to the uploadwizard so that it'll give some
informative message to the user when a file is blocked due to blacklisted
extension.

(Sorry guys, it takes time to get used to how stuff works here).
Comment 13 Tomer A. 2011-10-14 11:32:23 UTC
As I suspected, this was fixed in r80766 without also fixing the API upload.
Comment 14 Neil Kandalgaonkar 2011-12-15 19:25:54 UTC
Can I get a clarification here -- the bug is that the UploadWizard does not tell you which of the extensions caused the problem, if you somehow sneak a file in that is not allowed?

I can't even cause this to happen locally, can you give me an example configuration where it would happen?

Also, I don't think just changing the message to include a '$1' is going to fix this, you also need to change how the code works.
Comment 15 Tomer A. 2011-12-15 19:44:02 UTC
The way I see it, the uploadWizard should get this information from the API. Therefore, $1 should be enough for that. 

The real problem is that the API does not provide this info.

There's also a patch for the API in this tread that could have give more usful information had not been sitting here for two months.
Comment 16 drecodeam 2012-04-14 17:34:10 UTC
The message class that the Upload Wizard patch addresses were removed in this revision : https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/UploadWizard.git;a=blobdiff;f=UploadWizard.i18n.php;h=327448363c4f68a5ed973413d1594ffde30f60ff;hp=32bb094a0c7f152c8af53165693afad3f5990cae;hb=989d18720289aa47d4d0949494c5b9b6a968febc;hpb=b5d699ff016d3dc6428b1d8264b08d301d31935d. 
@Tomer, can you check the revision, and see if the problem still persists.
Comment 17 Tomer A. 2012-04-21 17:12:20 UTC
It is unlikely I'll have time in the near future.
Comment 18 Sumana Harihareswara 2012-06-13 19:00:30 UTC
Brad, do you have time to do any review and updates here?
Comment 19 Brad Jorsch 2012-07-19 17:26:12 UTC
I wound up rewriting both patches: the API one to provide all the blacklisted extensions and a better error message, and the UploadWizard one because due to subsequent changes the old patch wouldn't work right at all.

The new patches are Gerrit change #16040 and Gerrit change #16041.
Comment 20 matanya 2012-08-12 05:57:03 UTC
16040 was merged, 16041 is pending review.
Comment 21 Sumana Harihareswara 2012-10-10 19:53:28 UTC
16041 is now merged so I presume this is fixed, and am marking as such. Thanks, Brad.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links