Bug #69279 [Ver->Csd]: Compressed ZIP Phar extractTo() creates garbage files

Edit report at https://bugs.php.net/bug.php?id=69279&edit=1 ID: 69279 Updated by: cmb@php.net Reported by: mario at include-once dot org Summary: Compressed ZIP Phar extractTo() creates garbage files -Status: Verified +Status: Closed Type: Bug Package: PHAR related Operating System: * PHP Version: 7.4 Assigned To: cmb Block user comment: N Private report: N New Comment: Automatic comment on behalf of cmbecker69@gmx.de Revision: http://git.php.net/?p=php-src.git;a=commit;h=68f5289e9e84b12b1a9ad671657702ce9a65a1e1 Log: Fix #69279: Compressed ZIP Phar extractTo() creates garbage files Previous Comments: ------------------------------------------------------------------------ [2021-01-12 14:50:35] cmb@php.net The following pull request has been associated: Patch Name: Fix #69279: Compressed ZIP Phar extractTo() creates garbage files On GitHub: https://github.com/php/php-src/pull/6599 Patch: https://github.com/php/php-src/pull/6599.patch ------------------------------------------------------------------------ [2015-08-02 21:53:22] stas@php.net PharData has the same problem (probably the same code) - this code on a zip file: <?php $phar = new PharData('TestFile.zip'); $phar->extractTo('test'); when TestFile.zip contains text files, produces garbage files as a result. Looks like Phar fogets to uncompress the data or something like that. ------------------------------------------------------------------------ [2015-08-02 21:51:10] stas@php.net Related To: Bug #70019 ------------------------------------------------------------------------ [2015-03-23 01:32:29] mario at include-once dot org Description: ------------ See also #50797 - "PHAR fails to extract ZIP archives, but TAR is ok", which seems to document the same issue. Phar::extractTo() creates compressed/garbage output. Extracted files match the recorded file sizes. But they'll contain some binary content instead of the actual and decompressed file contents. It seems extractTo slices out raw ZIP archive contents, 18 bytes after the stored filename of the local PK file header. This behaviour isn't specific to 5.6.x, happened throughout 5.3, 5.4 and 5.5 too. (Example run against 5.6.6-1~dotdeb.1/ZTS/amd64.) An interesting workaround btw, is to use the phar:// streamwrapper prior. If a compressed file from the ZIP is accessed (per file_get_contents("phar://test.phar.zip/phar-test.txt") beforehand), then Phar::extractTo can reproduce the original file content. Test script: --------------- define('PHAR_FNAME', "test.phar.zip"); define('SAMPLE_FN', "phar-test.txt"); define('SAMPLE_TXT', "Sample content.\n"); // Create ZIP+GZ-Phar $w = new Phar(PHAR_FNAME); $w[SAMPLE_FN] = SAMPLE_TXT; $w->compressFiles(Phar::GZ); // Open anew $r = new Phar(PHAR_FNAME); assert($r[SAMPLE_FN]->isCompressed()); // Extract to file and compare to sample: fails $r->extractTo(".", NULL, TRUE); assert(SAMPLE_TXT === file_get_contents(SAMPLE_FN)); Expected result: ---------------- Example test.phar.zip UEsDBAAAAAAIAPIOd0a3HaQhEgAAABAAAAANABIAcGhhci10ZXN0LnR4dG51DgBXK0GEtg EAAAAAAAAAAAtOzC3ISVVIzs8rSc0r0eMCAFBLAwQAAAAACADyDndGmVatcj4AAAA8AAAA DgASAC5waGFyL3N0dWIucGhwbnUOAFcrQYS2AQAAAAAAAAAAs7EvyChQ0NdXqMos0E1KLE 5NUSjISCxSSCxKzsgsS1UoLilNUkjLzEnlio/3cPQJiXf29w3w9HEN0tC0BgBQSwMEAAAA AAAAAAgh7IqfoyccAAAAHAAAABMAEgAucGhhci9zaWduYXR1cmUuYmlubnUOAP8S2UEAAA AAAAAAAAAAAgAAABQAAAC/Ml0QwRjS2lNjdmUVA5Z1AsltwFBLAQIAAAAAAAAIAPIOd0a3 HaQhEgAAABAAAAANABIAAAAAAAAAAAAAAAAAAABwaGFyLXRlc3QudHh0bnUOAFcrQYS2AQ AAAAAAAAAAUEsBAgAAAAAAAAgA8g53RplWrXI+AAAAPAAAAA4AEgAAAAAAAAAAAAAATwAA AC5waGFyL3N0dWIucGhwbnUOAFcrQYS2AQAAAAAAAAAAUEsBAgAAAAAAAAAAAAgh7Iqfoy ccAAAAHAAAABMAEgAAAAAAAAAAAAAAywAAAC5waGFyL3NpZ25hdHVyZS5iaW5udQ4A/xLZ QQAAAAAAAAAAAABQSwUGAAAAAAMAAwDuAAAAKgEAAAAA Actual result: -------------- The "Sample content.\n" from test-phar.txt gets created as: 4e0b2dcc49c84855cfce492b2bcde3d1 N�-�IUH��+I�+� ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=69279&edit=1