Bug 244681 - archivers/unzip: handle trailing 0s in extra fields
Summary: archivers/unzip: handle trailing 0s in extra fields
Status: Closed Not Accepted
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: 2021-01-15 10:45 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.
Comment 6 Michael Osipov 2021-01-15 08:41:14 UTC
Please explain what you closed this issue although this is a valid case.
Comment 7 Emanuel Haupt freebsd_committer 2021-01-15 08:52:47 UTC
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.
Comment 8 Michael Osipov 2021-01-15 08:53:46 UTC
(In reply to Emanuel Haupt from comment #7)

I can agree with that.
Comment 9 Emanuel Haupt freebsd_committer 2021-01-15 10:45:23 UTC
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