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.
> /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://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
> $ /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.