Bug 243738 - unzip cannot handle LZMA-compressed ZIP-entries
Summary: unzip cannot handle LZMA-compressed ZIP-entries
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-30 19:03 UTC by Mikhail Teterin
Modified: 2020-02-20 23:48 UTC (History)
4 users (show)

See Also:


Attachments
Sample script to build ZIP-files with LZMA-compressed entries (199 bytes, text/plain)
2020-01-30 19:03 UTC, Mikhail Teterin
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mikhail Teterin freebsd_committer freebsd_triage 2020-01-30 19:03:39 UTC
Created attachment 211204 [details]
Sample script to build ZIP-files with LZMA-compressed entries

Any entry in a ZIP-file, that was compressed using LZMA, can be listed, but cannot be extracted. This is true for both unzip(1) and tar:

    unzip: lzma unknown error 1

and

    x core.26303.txt: lzma unknown error 1
    tar: Error exit delayed from previous errors.

Unzip installed by archivers/unzip cannot handle such entries either, but 7za can.

Both tar and unzip already link with liblzma, so it should be working, but does not -- and with the same message. Which suggests, the problem is with libarchive...

Attaching a Python-script, with which such ZIP-files can be created:

    ./ziplzma.py foo.zip file1 file2 ...
Comment 1 Conrad Meyer freebsd_committer freebsd_triage 2020-01-31 00:13:01 UTC
Reproduces on CURRENT.
Comment 2 Hans Christian Woithe 2020-02-08 13:59:14 UTC
I was also able to reproduce the problem.
It seems this was fixed in libarchive commit c8d40b27 issue #1257.

use the program above to create a test.zip file
$ echo "test" > test.txt
$ python3.6 ziplzma.py test.zip test.txt
$ rm test.txt

$ unzip -o test.zip
unzip: lzma unknown error 1

$ cd /tmp
$ git clone https://github.com/libarchive/libarchive.git
$ cd libarchive
$ git checkout c8d40b27
$ build/autogen.sh
$ ./configure
$ make

$ LD_PRELOAD="/tmp/libarchive/.libs/libarchive.so" unzip -o test.zip

This fix should be part of r356212.
So instead of the above procedure, you should be able make lib/archive and LD_PRELOAD the generated library.
In my testing environment that's currently in /usr/obj/...

$ LD_PRELOAD="/usr/obj/.../amd64.amd64/lib/libarchive/libarchive.so" unzip -o test.zip
Comment 3 Martin Matuska freebsd_committer freebsd_triage 2020-02-12 23:10:11 UTC
Libarchive 3.4.2 will be merged to 12-STABLE, 11-STABLE and 10-STABLE in about 1 week.
Comment 4 Mikhail Teterin freebsd_committer freebsd_triage 2020-02-20 23:41:54 UTC
I noticed an upgrade to src/contrib/libarchive, rebuilt my 11.x world and voila, both unzip(1) and tar(1) can now extract files put together with my sample Python-script. Thank you.

The libarchive commit didn't mention this ticket, can it be closed or must something else happen (like 10.x update)?
Comment 5 Conrad Meyer freebsd_committer freebsd_triage 2020-02-20 23:48:06 UTC
10.x is an EOL branch.  Given the fix in 11, I think this can be resolved.