Consider archiving unzip and provide it as a symlink to bsdunzip (from libarchive)

[Xi Ruoyao]

I cannot see any advantage of the old and unmaintained unzip comparing to bsdunzip.

[Douglas R. Reno]

I'm in fair of doing this as well, but we'll need to do some testing for packages like libreoffice which use it during it's build process.

[zeckma]

I can do some testing myself in a bit for packages like Firefox and Thunderbird. I want to test the Node.js dependency anyway.

[zeckma]

Replying to zeckma:

I can do some testing myself in a bit for packages like Firefox and Thunderbird. I want to test the Node.js dependency anyway.

Firefox, Thunderbird, and Seamonkey built fine after deleting the UnZip binaries, then making unzip symlink pointing to bsdunzip from libarchive.

[Xi Ruoyao]

Some git tests fails with the symlink, I'll investigate it later once I set up my working environment in the newly built system (I'm typing this in Lynx). Those tests can be suppressed with GIT_UNZIP=nonexist. And now our Git page does not list unzip as a dependency at all...

[Xi Ruoyao]

Doing so will also "fix" ​CVE-2021-4217.

[Xi Ruoyao]

Going to do this (also adding GIT_UNZIP=nonexist for Git test suite) if no further objection, considering we have a security issue here.

[Douglas R. Reno]

That sounds good to me, but please test building Libreoffice with the symlink, as it uses unzip very heavily throughout it's build process to unzip it's downloaded tarballs. I can test this instead if you'd like, just let me know since I'll probably update Libreoffice at the same time as testing it if we do this :)

[Joe Locash]

Replying to Douglas R. Reno:

That sounds good to me, but please test building Libreoffice with the symlink, as it uses unzip very heavily throughout it's build process to unzip it's downloaded tarballs. I can test this instead if you'd like, just let me know since I'll probably update Libreoffice at the same time as testing it if we do this :)

I just finished a test build of libreoffice-25.2.0.3 with the symlink and there were no issues.

[Xi Ruoyao]

The progress:

Tested:

• Mozilla trios
• libreoffice
• Git (test only, need to be disabled)
  • unzip -a is documented as "auto-convert any text files" but bsdunzip -a is documented as "convert DOS‐style line endings to Unix‐style line endings" (i.e. old Mac style isn't converted).
• fontconfig (test only)
• docbook-45-xml
• docbook5
• perl-archive-zip (test)
• sqlite (doc)
• docbook-4.5-dtd
• docbook-3.1-dtd
• ark
• file-roller
• lynx
• openjdk
• mc
• opencv

Need to be adapted:

• xarchiver (make 7zip the default, change the dependency to external)
• libgsf (test only, change the dependency to external)

Untested:

• gucharmap

Help needed for testing the remaining packages and/or providing the method to test them.

[Joe Locash]

mc, libgsf, opencv, gucharmap, and lynx all build fine using the symlink.

With libgsf I saw no mention of unzip at all in the logs and in the make check 2 valgrind tests were skipped instead of failing. It happens if valgrind is installed or not.

[Xi Ruoyao]

Replying to Joe Locash:

mc, libgsf, opencv, gucharmap, and lynx all build fine using the symlink.

With libgsf I saw no mention of unzip at all in the logs and in the make check 2 valgrind tests were skipped instead of failing. It happens if valgrind is installed or not.

libgsf needs both p7zip and unzip or these tests won't run.

The problem with lynx is unzip is used at runtime (for the "directory editor") so we need to manually test it. Similarly for things like xarchiver or file-roller.

[Douglas R. Reno]

Getting lynx to do this required a bit of configuration

• Edit /etc/lynx/lynx.cfg
• Run something like "lynx ​file:///sources/sqlite/"
• Select sqlite-doc-{something}.zip and then press F
• Press Enter on Uncompress

That being said, lynx works with the symbolic link. I'm testing the others on another system while I wait on Libreoffice to finish on my main one.

[Douglas R. Reno]

JDK builds and runs with the symlink

[Douglas R. Reno]

file-roller and Ark work well.

xarchiver on the other hand has some issues. It returns an error message saying "Zipinfo mode needs additional options".

[Douglas R. Reno]

I ran xarchiver from a terminal and it looks like it's running the following command:

/usr/bin/unzip -Z -l /home/renodr/sqlite-doc-3370200.zip

[Xi Ruoyao]

I'll take a look at xarchiver.

[Douglas R. Reno]

That sounds good, I think after that the archival and then replacement symlink should be good to go

[Xi Ruoyao]

If I read the xarchiver code correctly, when 7za (from p7zip or 7zip, see also #21047) is available it's preferred over unzip for the zip files. Thus maybe we can recommend p7zip/7zip for xarchiver for zip files.

Another option is adapting xarchiver to support bsdtar --list --verbose -f instead of unzip -Z -l but it would be more difficult.

[Douglas R. Reno]

It looks like users will need to uncheck the "Prefer unzip for zip files (requires restart)" option in Preferences, but after doing that and restarting xarchiver, it now works with p7zip!

[Xi Ruoyao]

Replying to Douglas R. Reno:

It looks like users will need to uncheck the "Prefer unzip for zip files (requires restart)" option in Preferences, but after doing that and restarting xarchiver, it now works with p7zip!

I also tried 7zip and it works as well. But I need to figure out how to make the default of this option off...

[Xi Ruoyao]

sed '/TOGGLE.*prefer_unzip/s/TRUE/FALSE/' -i src/pref_dialog.c

[Xi Ruoyao]

libgsf test suite wants the "zipinfo" command, which won't be available with the symlink.

[Xi Ruoyao]

mc checks if unzip supports the -Z flag at the build time, and it falls back to unzip -qq -v if -Z is not usable. bsdunzip supports the latter properly.

[Xi Ruoyao]

opencv tested. It seems only used for extracting a download file at build time.

[Xi Ruoyao]

gucharmap tested. Only used for extracting UCD.zip and Unihan.zip.

[Xi Ruoyao]

Fixed r12.2-1247-g32863364dd. I'll write the SA later.

[Xi Ruoyao]

SA 12.2-084.