[wp-trac] [WordPress Trac] #39963: MIME Alias Handling

[WordPress Trac]

#39963: MIME Alias Handling
--------------------------------------+-----------------------------
 Reporter:  blobfolio                 |       Owner:
     Type:  enhancement               |      Status:  reopened
 Priority:  normal                    |   Milestone:  5.0
Component:  Media                     |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:  administration
--------------------------------------+-----------------------------

Comment (by blobfolio):

 Thanks @joemcgill!

 I just attached an example data file. It is only around 150KB and contains
 information on 1978 different file extensions. Variations like `x-` and
 `vnd.` have been stripped out; those will be discovered as part of the
 alias matching function (separate from this file), so that saves some
 space.

 My thinking is that every aspect of this enhancement is progressive. The
 existing `upload_mimes` functionality shouldn't be messed with, and
 whatever MIME type that list declares something to be, that's what should
 ultimately be used (when e.g. saving an attachment).

 What we'd be adding with this enhancement (aside from the alias array) are
 a couple small functions to check that MIME/ext pairs are appropriate
 (particularly in cases where the MIME comes from outside WP and might
 disagree with the `upload_mimes` entry). Those functions could then be
 added to `wp_check_filetype_and_ext` to make upload validation more
 accurate (we can detect and block bad files, but also fix incorrectly
 named ones).

 Insofar as maintenance, the only piece that will need to be updated is the
 MIME data itself. I already have a build script for this, so it is really
 easy to regenerate. I'll push it somewhere public once we're in agreement
 on the file contents. As-is, the file contains a function and filter
 called `wp_get_mime_aliases`. I don't think it needs more than that.

 > I'm curious if we could limit the (massive) list in mimes.3.diff​ to
 only include mimes that are currently supported by WordPress...

 I think it would be better to handle all files out-of-the-box. Many users
 add types to WordPress through plugins, and those plugins aren't going to
 be capable of populating this data on their own. Again, we're only looking
 at about 150KB of data, so I'd rather not risk the UX/security
 implications from shortening it.

 > I like the idea of putting application/octet stream MIMES through an
 extra set of checks...

 With proper alias handling, we should be checking ''all'' uploaded
 content. That's the real security benefit here. Initially I think we
 should just continue using `fileinfo.so` when available, but down the road
 we could definitely make our own Magic Header script to strategically
 examine files for users who don't have that PHP extension installed.

 My plan is to put together an updated patch for this this weekend! I'll
 post it here when that's ready.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/39963#comment:36>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform