Bug 244681 - archivers/unzip: handle trailing 0s in extra fields
Summary: archivers/unzip: handle trailing 0s in extra fields
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Emanuel Haupt
Keywords: needs-patch
Depends on:
Reported: 2020-03-08 13:55 UTC by Michael Osipov
Modified: 2020-03-09 09:17 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (ehaupt)


Note You need to log in before you can comment on or make changes to this bug.
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.


> /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 freebsd_committer 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://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
> 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 freebsd_committer 2020-03-09 09:17:21 UTC
Unfortunately libarchive (bsdtar) does not support infozip, that's why we still need this port.