Bug #74573 [Com]: finfo_file apk

From: Date: Thu, 11 May 2017 16:23:51 +0000
Subject: Bug #74573 [Com]: finfo_file apk
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-209074@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=74573&edit=1 ID: 74573 Comment by: 209721949 at qq dot com Reported by: 209721949 at qq dot com Summary: finfo_file apk Status: Not a bug Type: Bug Package: *General Issues Operating System: mac PHP Version: 7.1.4 Block user comment: N Private report: N New Comment: to spam2. thank you ! i'm not good at english ,and i don't look at your comment carefully, but now i know it.thank you! Previous Comments: ------------------------------------------------------------------------ [2017-05-11 16:20:24] requinix@php.net .docx is only recognized (with what I've tested with) if the ZIP is packaged with the [Content_Types].xml as the first entry. Reorganizing the archive turns it into a regular "Zip archive", even though it's still a valid .docx file. .apk can apparently be recognized as a Jar file but that's as far as it goes. > can it be implemented in the future? Only if standard magic databases are able to identify it, and currently it does not appear that they can. Just because there is a MIME identifier for a file does not mean it can be reliably identified from the file's data. Which is what this all does, if you weren't aware. And @spam2: stop using this bug report as your soapbox. ------------------------------------------------------------------------ [2017-05-11 16:14:35] spam2 at rhsoft dot net > can it be implemented in the future as you can see in my tests the reason is PHP before 7.2 is using a libmagic from the last decade and so test it with a recent operating system and "/usr/bin/file -b --mime-type <file>" - if it's correct chances are good that with 7.2 it will be fine or ask enough people to make pressure backporting the stuff below so people using a distribution package have the slightest chance to see that improved before 2020 [2016-11-25 00:01 UTC] ab@php.net 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. ------------------------------------------------------------------------ [2017-05-11 16:07:41] 209721949 at qq dot com since .apk file has it's own mime type, i think it's better to get the right mime type directly and correct, just like other types of file, can it be implemented in the future ? ------------------------------------------------------------------------ [2017-05-11 15:48:52] spam2 at rhsoft dot net > requinix@php.net: .apk files are ZIP archives yeah, openoffice documents are ZIP files too *but* they are recognized because it's the underlying libmagic - *maybe* for that case it's true and a recent libmagic would have the same result but be careful to classify that as "not a bug" with current head from https://github.com/zendtech/php-src /just beause also test the experimental JIT at the same time a) "php ext/fileinfo/create_data_file.php" against a Fedora 25 libmagic works b) the sample from https://bugs.php.net/bug.php?id=67516 is correctly detected as image/gif and no longer application/octet-stream c) it is proven that fileinfo in PHP is broken by deign for years ------------------------------------------------------------------------ [2017-05-11 15:36:21] spam2 at rhsoft dot net just tested it again with PHP 7.1.5 "/usr/bin/php ext/fileinfo/create_data_file.php /usr/share/misc/magic.mgc > ext/fileinfo/data_file.c" *only seems* to work happily i included a large testsuite in our pgo-build and stop rpmbuild when it fails, no need for complete gcc-profiling and second buildstage when the result is a broken PHP, see below ________________________________________________________ frankly as i reported the bug i waited at least 2 years in the hope fileinfo get any updates, nothing.... so we have for at least 4 years a known image/gif detected as application/octet-stream which makes any verification of useruploads pointless when you need to allow "application/octet-stream" you case with "zip" is harmless, at least you can distinct it form a random executable :-) [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 ________________________________________________________ FAILED: NOT ALL TESTS PASSED [11-May-2017 17:31:22 Europe/Vienna] PHP Warning: finfo_open(): Failed to load magic database at '(null)'. in /Volumes/dune/www-servers/cms/cms/autotests/api_captcha.php on line 39 [11-May-2017 17:31:22 Europe/Vienna] CMS-AUTOTEST: cl_api->captcha->test() failed - TypeError: finfo_file() expects parameter 1 to be resource, boolean given in /Volumes/dune/www-servers/cms/cms/autotests/api_captcha.php:40 Stack trace: #0 /Volumes/dune/www-servers/cms/cms/autotests/api_captcha.php(40): finfo_file(false, '/Volumes/dune/w...', 16) #1 /Volumes/dune/www-servers/cms/cms/api_captcha.php(117): require('/Volumes/dune/w...') #2 /Volumes/dune/www-servers/cms/cms/autotest.php(457): cl_captcha->test() #3 {main} [11-May-2017 17:31:25 Europe/Vienna] PHP Warning: finfo_open(): Failed to load magic database at '(null)'. in /Volumes/dune/www-servers/phpincludes/global_rh_misc.inc.php on line 3407 [11-May-2017 17:31:25 Europe/Vienna] PHP Warning: finfo_open(): Failed to load magic database at '(null)'. in /Volumes/dune/www-servers/phpincludes/global_rh_misc.inc.php on line 3407 [11-May-2017 17:31:25 Europe/Vienna] PHP Warning: finfo_open(): Failed to load magic database at '(null)'. in /Volumes/dune/www-servers/phpincludes/global_rh_misc.inc.php on line 3407 ------------------------------------------------------------------------ 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=74573 -- Edit this bug report at https://bugs.php.net/bug.php?id=74573&edit=1

« previous php.bugs (#209074) next »