A program to unpack compressed files

Edit Package unzip
http://www.info-zip.org/

UnZip is an extraction utility for archives compressed in .zip format
(known as "zip files"). Although highly compatible both with PKWARE's
PKZIP(tm) and PKUNZIP utilities for MS-DOS and with Info-ZIP's own Zip
program, our primary objectives have been portability and non-MS-DOS
functionality. This version can also extract encrypted archives.

Refresh
Refresh
Source Files
Filename Size Changed
unzip-5.52-filename_too_long.patch 0000001210 1.18 KB
unzip-5.52-use_librcc.patch 0000004686 4.58 KB
unzip-iso8859_2.patch 0000007716 7.54 KB
unzip-no_file_name_translation.patch 0000003873 3.78 KB
unzip-open_missing_mode.patch 0000001553 1.52 KB
unzip-optflags.patch 0000001111 1.08 KB
unzip.changes 0000008691 8.49 KB
unzip.dif 0000000749 749 Bytes
unzip.spec 0000002785 2.72 KB
unzip60.tar.bz2 0001063255 1.01 MB
Revision 8 (latest revision is 64)
Philipp Thomas's avatar Philipp Thomas (psmt) committed (revision 8)
- Update to 6.0:
  *  Support PKWARE ZIP64 extensions, allowing Zip archives and Zip archive
     entries larger than 4 GiBytes and more than 65536 entries within a
     single Zip archive.  This support is currently only available for Unix,
     OpenVMS and Win32/Win64.
  * Support for bzip2 compression method.
  * Support for UTF-8 encoded entry names, both through PKWARE's "General
    Purpose Flags Bit 11" indicator and Info-ZIP's new "up" unicode path
    extra field.  (Currently, on Windows the UTF-8 handling is limited to
    the character subset contained in the configured non-unicode "system
    code page".)
  * Fixed "Time of Creation/Time of Use" vulnerability when setting
    attributes of extracted files, for Unix and Unix-like ports.
  * Fixed memory leak when processing invalid deflated data.
  * Fixed long-standing bug in unshrink (partial_clear), added boundary
    checks against invalid compressed data.
  * On Unix, keep inherited SGID attribute bit for extracted directories
    unless restoration of owner/group id or SUID/SGID/Tacky attributes was
    requested.
  * On Unix, allow extracted filenames to contain embedded control
    characters when explicitly requested by specifying the new command line
    option "-^".
  * On Unix, support restoration of symbolic link attributes.
  * On Unix, support restoration of 32-bit UID/GID data using the new "ux"
    IZUNIX3 extra field introduced with Zip 3.0.
  * Support symbolic links zipped up on VMS.
  * New -D option to suppress restoration of timestamps for extracted
    directory entries (on those ports that support setting of directory
    timestamps).  By specifying "-DD", this new option also allows to
    suppress timestamp restoration for ALL extracted files on all UnZip
    ports which support restoration of timestamps.  On VMS, the default
    behaviour is now to skip restoration of directory timestamps; here,
    "--D" restores ALL timestamps, "-D" restores none.
  * On OS/2, Win32, and Unix, the (previously optional) feature UNIXBACKUP
    to allow saving backup copies of overwritten files on extraction is now
    enabled by default.
Comments 2

Kira Marie Backes's avatar

There is a huge and probably very old bug in openSUSE unzip (Tumbleweed as well as 15.3). This bug is fixed in Ubuntu's unzip version, I looked at their patches and there's several CVEs missing here, and I assume it's one of these patches that fixed the issue.

The bug is when extracting an archive where file permissions are not explicitly set, occasionally (but reproducibly) one or more files get converted to be symlinks and the original content of the file is suddenly the link target.

This can easily be reproduced by downloading the zip archives from the Shopware/Platform project, e.g. https://github.com/shopware/platform/archive/dd2bf30d0519dcd9416dc269c88edcfd66f92add.zip

When downloading this zip archive and extracting it in the console with unzip the file platform-dd2bf30d0519dcd9416dc269c88edcfd66f92add/src/Storefront/Resources/app/storefront/dist/assets/icon/default/editor-redo.svg gets erroneously converted into a symlink. The fun thing about this bug is that you can reproduce it with nearly every single zip of a commit and it's always different files, but when extracting the same archive it's always the same file(s) that get converted into a symlink. This bug has caused us a lot of issues for the past year.

I guess it's one of the not applied patches you can see here: https://sources.debian.org/patches/unzip/6.0-26/

kind regards, Kira Backes


openSUSE Build Service is sponsored by