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.
Looks good to me. Can you provide a patch for the port?
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.
(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.
(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
Unfortunately libarchive (bsdtar) does not support infozip, that's why we still need this port.
Please explain what you closed this issue although this is a valid case.
It is not a FreeBSD specific issue. Either someone has to come up with a patch to implement the requested improvement or even better it has to be implemented by the upstream author. Tracking this here in the FreeBSD bug system is not the right place.
(In reply to Emanuel Haupt from comment #7) I can agree with that.
Sorry, I should have written this in the close message. Probably the best place to report the bug would be: http://infozip.sourceforge.net/zip-bug.html