|Summary:||archivers/unzip: handle trailing 0s in extra fields|
|Product:||Ports & Packages||Reporter:||Michael Osipov <michael.osipov>|
|Component:||Individual Port(s)||Assignee:||Emanuel Haupt <ehaupt>|
|Severity:||Affects Many People||CC:||daniel.engberg.lists, michael.osipov|
Description Michael Osipov 2020-03-08 13:55:44 UTC
There seems to be ZIP files which contain trailing 0s in the extra fields. Unzip reports: /usr/local/bin/unzip -tq f0a8... > <filename> bad extra-field entry: > EF block length (0 bytes) invalid (< 4) This comes from patch-extract.c. But > /usr/bin/unzip -tq f0a8... > No errors detected in compressed data of f0a8... This has also been reported with https://github.com/libarchive/libarchive/issues/1056 and fixed there with https://github.com/libarchive/libarchive/commit/c2f931fc20e57bb6721b40d1fc3cff2d4e92496d Such a patch should also be backported for this port.
Comment 1 Emanuel Haupt 2020-03-08 20:21:42 UTC
Looks good to me. Can you provide a patch for the port?
Comment 2 daniel.engberg.lists 2020-03-09 08:25:22 UTC
Perhaps it might worth considering retiring unzip and convert ports to use bsdtar instead especially given that it hasn't been updated by upstream in 10+ years. There's also another issue apparently which hasn't been adressed by upstream named zip bomb https://sourceforge.net/p/infozip/bugs/53/ . https://www.extremetech.com/computing/294852-new-zip-bomb-stuffs-4-5pb-of-data-into-46mb-file https://github.com/madler/unzip/commits/master this fork seems to adress that issue however.
Comment 3 Michael Osipov 2020-03-09 09:00:06 UTC
(In reply to Emanuel Haupt from comment #1) I need to look at this, but my C knowledge is mediocre and when I looked at the source code for finding other issues, it is a mess. I'll try in the next couple of weeks.
Comment 4 Michael Osipov 2020-03-09 09:07:59 UTC
(In reply to daniel.engberg.lists from comment #2) It would require the command line to be completely replicated with base unzip. Moreover, I also need zipinfo. When you compare both "unzip -Z" you'll see that base's is unusable. > $ /usr/bin/unzip -Z1 zip-test.jar > META-INF/MANIFEST.MF > test/ > test/ZipTest.class > $ /usr/bin/unzip -Z zip-test.jar > Zipinfo mode needs additional options > $ /usr/local/bin/unzip -Z zip-test.jar > Archive: zip-test.jar > Zip file size: 1921 bytes, number of entries: 3 > -rw---- 2.0 fat 66 bX defN 19-Aug-19 15:09 META-INF/MANIFEST.MF > -rw---- 1.0 fat 0 b- stor 19-Aug-15 18:10 test/ > -rw---- 2.0 fat 3094 bl defN 19-Aug-19 15:08 test/ZipTest.class > 3 files, 3160 bytes uncompressed, 1545 bytes compressed: 51.1% There is much work need to be done to have base unzip to be equivalent. See why I came here: https://lists.freebsd.org/pipermail/freebsd-questions/2020-March/288177.html
Comment 5 Emanuel Haupt 2020-03-09 09:17:21 UTC
Unfortunately libarchive (bsdtar) does not support infozip, that's why we still need this port.