what i completly don't understand is why PHP obviously brings it's on mime-magic and static implementation instead just use the operating systems file-libs

i tried this example with gif image size:8.2m
and i get this result:
/usr/bin/file -b --mime-type
image/gif

finfo_file(filename, FILEINFO_MIME_TYPE)
image/gif
it's work

i know by myself that it works for most files, but this bugtracker lacks capability to attach the affected file, 

anyways, if php would use systems file-utilities/libraries the behavior of PHP and other applications would be indetical and it would not need to carry some MB of redundant data

Usage of external libmagic isn't possible for various reasons, the patched version is tightly integrated with PHP. 

@spam2, @fayez, which file/PHP versions was used?

@spam2, please post the image you've an issue with to http://picpaste.com/ . You could probably check with bug #68731 whether it's reproducible for you.

Thanks.

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.

no feedback was provided?

i said "sadly i don't see here any option to attach the image" in the original report and a *really* interested developer would have offered to send the file per mail to him - what feedback do you expect on a bugtracker from the early 1990's with no capabilities?

As @ab has already said, you can upload the image file to
http://picpaste.com/, and of course there are lots of other
similar hosting services. Alternatively, you can make the file
available for download on (one of) your own server(s).

Please change the status of the bug report to "Open", when you're
replying. Otherwise the status will be automatically changed to
"No Feedback" after two weeks.

https://access.thelounge.net/harry/php-mimetype-bug.gif

the PHP version don't matter, it happens with 5.5 for over a year as well as with recent 5.6.11 builds for that file and i don't get "Usage of external libmagic isn't possible for various reasons" while all other software out there can use system libraries

> you can upload the image file to http://picpaste.com/

seriously? a GIF coverted to jpeg and "The picture shown above was automatically resized!" wil hadrly help to debug a issue with the original.....

Thanks for making the file available, and sorry for the bad
pointer to picpaste.com.

Anyhow, a quick check:

    cmb@debian64:~$ file -b --mime-type 67516.gif
    application/octet-stream
    cmb@debian64:~$ dpkg -s file
    Package: file
    Status: install ok installed
    Priority: standard
    Section: utils
    Installed-Size: 119
    Maintainer: Christoph Biedl <debian.axhn@manchmal.in-ulm.de>
    Architecture: amd64
    Multi-Arch: foreign
    Version: 1:5.22+15-2
    Depends: libc6 (>= 2.4), libmagic1 (= 1:5.22+15-2), zlib1g (>= 1:1.1.4)
    Description: Determines file type using "magic" numbers
     File tests each argument in an attempt to classify it. There are
     three sets of tests, performed in this order: filesystem tests,
     magic number tests, and language tests. The first test that
     succeeds causes the file type to be printed.
    Homepage: http://www.darwinsys.com/file/
    
Which version of file/libmagic do you use?

as said i build PHP from the unpatched upstream sources, so the libmagic is bundeled and that exists from 5.5.13 until 5.6.11 while the file-package from Fedora (cli command file) recognizes it correctly, hence i even wrote admin scripts calling the file-cli from PHP 

the problem is that at least for Fedora the distributions file-package becomes often updates in case of bugs and wrong recognized samples and PHP is always behind :-(

@rhsoft PHP uses a patched libmagic primarily to a) integrate with PHP filesystem APIs, including things like stream wrappers, but more importantly also open_basedir restrictions etc and b) to use our per-request allocator. If you're interested in what the differences are, have a look at https://github.com/php/php-src/blob/master/ext/fileinfo/libmagic.patch.

well, if it would be reasonable updated or at lest support the systems magic-data, with PHP 7.0.11RC1 still the same bugs as 2 years ago

[harry@srv-rhsoft:/data/lounge-daten/php-mimtype-bug]$ php mime.php
/mnt/data/lounge-daten/php-mimtype-bug/1.gif
/usr/bin/file -b --mime-type
image/gif

finfo_file(filename, FILEINFO_MIME_TYPE)
application/octet-stream

libmagic: 522
file-5.25-6.fc24.x86_64

file-5.22-1.fc21  2015-02-10 06:52:41
file-5.25-6.fc24  2016-02-03 22:20:33

and there where redhat bugfixes in the meantime about wrong detected files (some of them reported by me) PHP never has seen

well, in a perfect world on would be able to update 'data_file.c' with the script in the source tree before compile PHP, in the real world the file is updates, php builds but it don't work

what about someone takes afte rmore than a year a look why https://access.thelounge.net/harry/php-mimetype-bug.gif is recognized as application/octet-stream instead image/gif and considers to update the mime database?

i don't get all the excuses for not use the system libmagic - for open_basedir and streams-support one would need nothing else than a tiny wrapper doing that all with a tempfile which ins finally feeded to the system libmagic instead fork it completly

_______________________________________

%prep
%setup -q -n php-%{version}
%patch1 -p1

# generate 'data_file.c' from bundeled libmagic with current system data
/usr/bin/php ext/fileinfo/create_data_file.php /usr/share/misc/magic.mgc > ext/fileinfo/data_file.c
_______________________________________

[harry@rh:/data/lounge-daten/php-mimtype-bug]$ php mime.php
/mnt/data/lounge-daten/php-mimtype-bug/1.gif
/usr/bin/file -b --mime-type
image/gif

finfo_file(filename, FILEINFO_MIME_TYPE)

Warning: finfo_open(): Failed to load magic database at '(null)'. in /mnt/data/lounge-daten/php-mimtype-bug/mime.php on line 15

Warning: finfo_file() expects parameter 1 to be resource, boolean given in /mnt/data/lounge-daten/php-mimtype-bug/mime.php on line 16


Warning: finfo_close() expects parameter 1 to be resource, boolean given in /mnt/data/lounge-daten/php-mimtype-bug/mime.php on line 17

I can confirm that even latest master reports
"application/octet-sream" for "php-mimtype-bug.gif" with the
bundled magic.

> well, in a perfect world on would be able to update
> 'data_file.c' with the script in the source tree before compile
> PHP, in the real world the file is updates, php builds but it
> don't work

I can't reproduce this (generating a new data_file.c from Debian
Jessie's magic.mgc, compiling and using finfo works fine for me).
Anyhow, please open another ticket with regard to this issue.

However, 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(). Would that work for you, i.e.
would that produce the expected "image/gif"?

echo 'finfo_file(filename, FILEINFO_MIME_TYPE)' . "\n";
$finfo_handle = finfo_open(FILEINFO_NONE, '/usr/share/misc/magic.mgc');
echo finfo_file($finfo_handle, $path, FILEINFO_MIME_TYPE) . "\n";
__________________________________________________________

using the 'magic.mgc' from Fedora don't work this way too (besides it's practically not useable because of application portability and open_basedir-restrictions outside php.ini) and may explain why "/usr/bin/php ext/fileinfo/create_data_file.php /usr/share/misc/magic.mgc > ext/fileinfo/data_file.c" leads to a unusable 'fileinfo.so' extension

file-5.25-6.fc24.x86_64
file-libs-5.25-6.fc24.x86_64

https://koji.fedoraproject.org/koji/packageinfo?packageID=418

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
__________________________________________________________

Notice: finfo_open(): Warning: type `' invalid in /mnt/data/lounge-daten/php-mimtype-bug/mime.php on line 15

Notice: finfo_open(): Warning: offset `East_Side_Invertationa' invalid in /mnt/data/lounge-daten/php-mimtype-bug/mime.php on line 15

Notice: finfo_open(): Warning: type `East_Side_Invertationa' invalid in /mnt/data/lounge-daten/php-mimtype-bug/mime.php on line 15

Notice: finfo_open(): Warning: offset `The_Incinerator_Plant' invalid in /mnt/data/lounge-daten/php-mimtype-bug/mime.php on line 15

Notice: finfo_open(): Warning: type `The_Incinerator_Plant' invalid in /mnt/data/lounge-daten/php-mimtype-bug/mime.php on line 15

Notice: finfo_open(): Warning: offset `Takahiro_Laboratories' invalid in /mnt/data/lounge-daten/php-mimtype-bug/mime.php on line 15

Notice: finfo_open(): Warning: type `Takahiro_Laboratories' invalid in /mnt/data/lounge-daten/php-mimtype-bug/mime.php on line 15

Notice: finfo_open(): Warning: offset `<protocol bbn-m' invalid in /mnt/data/lounge-daten/php-mimtype-bug/mime.php on line 15

Notice: finfo_open(): Warning: type `<protocol bbn-m' invalid in /mnt/data/lounge-daten/php-mimtype-bug/mime.php on line 15

Notice: finfo_open(): Warning: offset `the_Slipgate_Complex' invalid in /mnt/data/lounge-daten/php-mimtype-bug/mime.php on line 15

Notice: finfo_open(): Warning: type `the_Slipgate_Complex' invalid in /mnt/data/lounge-daten/php-mimtype-bug/mime.php on line 15

Notice: finfo_open(): Warning: offset `Castle_of_the_Damned' invalid in /mnt/data/lounge-daten/php-mimtype-bug/mime.php on line 15

Notice: finfo_open(): Warning: type `Castle_of_the_Damned' invalid in /mnt/data/lounge-daten/php-mimtype-bug/mime.php on line 15

Notice: finfo_open(): Warning: offset `the_Dismal_Oubliette' invalid in /mnt/data/lounge-daten/php-mimtype-bug/mime.php on line 15

Notice: finfo_open(): Warning: type `the_Dismal_Oubliette' invalid in /mnt/data/lounge-daten/php-mimtype-bug/mime.php on line 15

Notice: finfo_open(): Warning: offset `Satan's_Dark_Delight' invalid in /mnt/data/lounge-daten/php-mimtype-bug/mime.php on line 15

Notice: finfo_open(): Warning: type `Satan's_Dark_Delight' invalid in /mnt/data/lounge-daten/php-mimtype-bug/mime.php on line 15

Notice: finfo_open(): Warning: offset `The_Tower_of_Despair' invalid in /mnt/data/lounge-daten/php-mimtype-bug/mime.php on line 15

Notice: finfo_open(): Warning: type `The_Tower_of_Despair' invalid in /mnt/data/lounge-daten/php-mimtype-bug/mime.php on line 15

Notice: finfo_open(): Warning: offset `The_Elder_God_Shrine' invalid in /mnt/data/lounge-daten/php-mimtype-bug/mime.php on line 15

Notice: finfo_open(): Warning: type `The_Elder_God_Shrine' invalid in /mnt/data/lounge-daten/php-mimtype-bug/mime.php on line 15

Notice: finfo_open(): Warning: offset `Shub-Niggurath's_Pit' invalid in /mnt/data/lounge-daten/php-mimtype-bug/mime.php on line 15

see https://bugs.php.net/bug.php?id=73046 for fail to use 'create_data_file.php' on Fedora 24 to get a recent 'fileinfo.so'

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

> 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>

@spam2 please link the RHEL tickets you've mentioned.

Thanks.

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

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.

given that this bugreport exists for more than 2 years "This is fixed in 7.2" is disappointing and the fact that one needs to use exec/passthru/popen which is a no-go in any secure environment but without you reject perfectly sane uplodas or need to accept application/oectect-stream which means "forget about mime-type checking at all" should make that clear

it's a completly wrong design decision that PHP needs a modified libmagic instead using the system ones which reveives reulgary updates and open_basedir is no excuse - you have to check open_basedir long before you touch libmagic at all

@spam2 at rhsoft dot net, what you say is not remotely true. There's absolutely no promise a distribution shipped libmagic is always correct. It would be much more constructive, if you could deliver a 7.2 test result with your app.

Thanks.

but there is a promise that it don't take 2 years until some fix is proposed which takes another 2 or 3 years to make it in a stable release because it's not a fork 

why do i need to build a PHP7.2 snapshot to test "my application" when the sample image is still available at https://access.thelounge.net/harry/php-mimetype-bug.gif and the oneliner "echo finfo_file(filename, FILEINFO_MIME_TYPE);" checks if it now correctly reports a image mimetype

@spam2 at rhsoft dot net, I can only repeat, that your statement is wrong. And probably add, that the discussion in this form is not expedient.

$ file php-mimetype-bug.gif
php-mimetype-bug.gif: DOS/MBR boot sector

Guess, which stable distribution this is. Your app could be running on it.

The PHP solution is not worse and not better, than the vanilla lib or a package provided by a distribution. It is a PITA for ext maintainers, not for you. There will be always a file failed to be recognized correctly - that is not an acceptance criteria for such a broad usage.

I've asked you to contribute by testing, to ensure the state stability with the real data in your app and to evaluate a possible backport chance. It's up to you. As for me - I retain from the further discussion of this kind.

Thanks.

Harald, you may want to read <https://bugs.php.net/how-to-report.php>. :-)

"I can only repeat, that your statement is wrong" is nonsense - for the cases where the sysem libmagic on Fedora had wrong results it took hours or a few days days until there was a koji build with a fix and not years
_______________________________

"I've asked you to contribute by testing, to ensure the state stability with the real data in your app and to evaluate a possible backport chance. It's up to you" - JUST GIVE ME A RECENT LIBMAGIC since uploads are verfied witin mod_security and the file command BECAUSE i can't trust PHP - so any libmagic from F22 to F25 is fine
_______________________________

> Guess, which stable distribution this is. Your app could be running on it

no it could not - my app is running on the current stable Fedora release where also development happens and don't need to run anywhere else since we develop and host it on own infrastrcuture where nobody but me take scare about software versions - only the outdated libmagic of PHP is out of my scope and since it's that outdated that even "/usr/bin/php ext/fileinfo/create_data_file.php /usr/share/misc/magic.mgc > ext/fileinfo/data_file.c" in the build-process does not work that's a problem
_______________________________

i explain it again:

if i ask on the same operating system two tools about the mimetype i expect the identical response - be it correct or wrong - point is when somebody sends me a image via email with the question "why does this dmaned cms-system not accept that image with a generic error message about wrong filetype" typing "file -b --mime-type attachemnt.gif" should give a answer - currently you get the expected result

BTW: wouldn't it be time at least instead having a 2 MB binary .so-extension to install the magicfile in the extensions folder and by default point to this file?

loading 2 MB unconditional in memory because someone *could* use a fileinfo-function is very questionable