Last modified: 2010-05-15 14:35:54 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 3641 - files with a bad extension are not rejected if their true mime type can not be determined (PATCH)
files with a bad extension are not rejected if their true mime type can not b...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Uploading (Other open bugs)
1.6.x
PC Linux
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-07 14:28 UTC by Daniel Kinzler
Modified: 2010-05-15 14:35 UTC (History)
0 users

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


Attachments
patch against head (1.00 KB, patch)
2005-10-07 14:29 UTC, Daniel Kinzler
Details
Fix to the fix (2.34 KB, patch)
2005-10-08 06:02 UTC, Brion Vibber
Details

Description Daniel Kinzler 2005-10-07 14:28:15 UTC
Currently, files that have a file extension that does not match their real mime
type are rejected ONLY if the real type can be determined. You could upload a
bunch of random bytes as a JPG. Note that the real mime type is determined by
$wgMimeDetectorCommand, finfo_open or mime_content_tye, depending on setup.

I suggest to change this behavior, see the patch attached. The patch does the
following:

IF the mime type can not be determined BUT the file extension is listed in
mime.info ($wgMimeInfoFile), reject the file. IF the mime type can not be
determined AND the file extension is NOT listed in mime.info, allow the file.

The only possible problem I see is this:

IF an "obscure" file type is allowed BUT that type is not recognized by the mime
detection AND the file extension is listed in mime.info, such files will be
rejected. The solution would be to remove that file type from mime.info (or
change the method of mime detection).
Comment 1 Daniel Kinzler 2005-10-07 14:29:00 UTC
Created attachment 946 [details]
patch against head
Comment 2 Ævar Arnfjörð Bjarmason 2005-10-07 19:40:27 UTC
FIXED in CVS HEAD
Comment 3 Brion Vibber 2005-10-07 20:56:48 UTC
This bug is a regression in 1.5; it doesn't always seem to trigger, but it can 
reproduce it on my Linux test box with $wgMimeDetectorCommand = 'file -bi'.

Applied fix to REL1_5 branch, will appear in 1.5.1.
Comment 4 Brion Vibber 2005-10-08 04:29:47 UTC
Patch is bad -- has broken uploads of all filetypes other than built-in images.

Reopening.
Comment 5 Brion Vibber 2005-10-08 06:02:22 UTC
Created attachment 950 [details]
Fix to the fix

Additional patch to fix the breakage of unrecognized types. Adds a separate
function MimeMagic::isRecognizableExtension() which just matches on extensions
which are known to be recognizable from their content (currently, the list of
types for getimagesize()). Extensions on that list will be rejected when
detection comes back with 'unknown'; extensions not on that list can't be
reliably detected from content so will be passed on as before.

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


Navigation
Links