Bug #67516 [Opn->Csd]: wrong mimetypes with finfo_file(filename, FILEINFO_MIME_TYPE)
| From: | ab@php.net | Date: | Fri, 25 Nov 2016 00:01:14 +0000 |
| Subject: | Bug #67516 [Opn->Csd]: wrong mimetypes with finfo_file(filename, FILEINFO_MIME_TYPE) | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-205624@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=67516&edit=1
ID: 67516
Updated by: ab@php.net
Reported by: spam2 at rhsoft dot net
Summary: wrong mimetypes with finfo_file(filename,
FILEINFO_MIME_TYPE)
-Status: Open
+Status: Closed
Type: Bug
Package: Filesystem function related
Operating System: Linux
PHP Version: 7.0.11
-Assigned To:
+Assigned To: ab
Block user comment: N
Private report: N
New Comment:
This is fixed in 7.2 with the libmagic upgrade https://github.com/php/php-src/commit/52f5b9659fa27936d8271c4d7a6874269fbf9534
. A packport into lower branches might be tricky, as libmagic 5.29 has quite some incompatibilities
to the current version - in the data format as well as in the actual code. It could be possible as a
complete upgrade in lower branches, but would mean yet more patching, however the new libmagic needs
to be ensured stable in 7.2 first.
Thanks.
Previous Comments:
------------------------------------------------------------------------
[2016-09-09 07:50:43] spam2 at rhsoft dot net
Fedora tickets - sorry, but there where over the years way too much not php related bugreports and
searching for "file" which is the package name leads to nowhere
anyways, there needs to be done something that PHP drifts that far form the rest of the world in
file detection - if i allow application/octet-stream for image extensions i can skip the complete
checks at all
------------------------------------------------------------------------
[2016-09-08 23:03:30] ab@php.net
@spam2 please link the RHEL tickets you've mentioned.
Thanks.
------------------------------------------------------------------------
[2016-09-08 23:00:28] ab@php.net
Related To: Bug #73046
------------------------------------------------------------------------
[2016-09-08 11:20:16] cmb@php.net
> i guess some format changed and hence to fork libmagic instead
> intrudce a shim-layer for streaming-support and openbase-dir is
> a historical mistake
It appears to me that there had also limitations of libmagic to be
solved. From a quick look at libmagic.patch[1], I see that the
memory management was hard-coded to malloc() and frieds, that
WIN32 might not have been supported at all, that an IS_STRING
macro is defined by libmagic which might clash with Zend's
IS_STRING, and that there also have been some bugs.
I agree, though, that patching an external library is unfortunate,
and the status of current libmagic should be reviewed. Perhaps
there are cleaner solutions possible now.
Patches are welcome!
[1] <https://github.com/php/php-src/blob/master/ext/fileinfo/libmagic.patch>
------------------------------------------------------------------------
[2016-09-08 11:20:14] spam2 at rhsoft dot net
BTW:
> it shouldn't be necessary to compile
> with a custom magic.mgc, because you
> could pass a custom magic.mgc directly
> as second parameter to finfo_open()
besides the current issues on Fedora 24 (se above and the otehr bugreport as requested) this
*really* deserves a "php.ini" parameter to make this system-wide *and* exclude the path
from open-basedir checks because it's form the server configuration (like session_savedir
don't need and must not be in the document root for security reasons as long it's not set
in .htaccess or with ini_set)
when one maintains hundrets of websites, including 3rd party code, want his applications to be
portable it's hard to maintain in the finfo_open() call
the whole goal:
if your application refuses a upload and you get the sample file be able to use the systems
file-command and get the same mimetype reported as the php application got by refuse it
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=67516
--
Edit this bug report at https://bugs.php.net/bug.php?id=67516&edit=1