![[Info-ZIP]](images/InfoZIP-gold2.png)
Short answer: ftp://ftp.info-zip.org/pub/infozip/ : either cd into an appropriate subdirectory and grab an appropriate executable distribution, or else get the source code from the src subdirectory and compile your own.
Long answer: do something similar to the following. This is for a Unix-like, text-mode ftp client, but others will work similarly. (The stuff after "//" is comments; don't type any of it. This example assumes you want UnZip for a Windows 9x or NT system, but the procedure is similar for other systems.)
ftp ftp.info-zip.org // run the ftp program and connect to Walnut Creek
anonymous // username for anonftp
[email protected] // use your real e-mail address for password
cd /pub/infozip // change into the Info-ZIP subdirectory
dir // list the contents of the subdirectory
cd WIN32 // change into the WIN32 subdirectory
dir // list the contents of the subdirectory
bin // set transfer mode to binary (IMPORTANT!)
get unz552xN.exe // get self-extracting Win32 UnZip 5.51 archive
quit // quit the ftp program
[Download unz552xN.exe in binary mode to your 32-bit Windows system if necessary.]
Remember: if the file size of the downloaded archive isn't EXACTLY the same as the size listed on the original ftp site with the "dir" command, you did something wrong. It is probably corrupted in that case. (Yes, this is a little harder to check via WWW since the size is usually given in KB or MB, but our README file in the same directory lists exact byte sizes. Also, most browsers automatically download in binary mode, so it shouldn't be a problem with them.)
Zip and UnZip executables for both OS/390 OpenEdition and OS/390 Base (a.k.a. MVS Classic) are now available here.
Note that we no longer have any mainframe folks among the core developers, so if you have problems or questions, try the mailing list(s), not the bug form. We cannot help you. This port is officially unsupported. (We will gratefully accept programming help, however!)
MacZip, a Macintosh port by Dirk Haase that includes both Zip and UnZip capability, was officially released in January 2000 and is available in both source and binary forms.
We currently have no plans to do a WinCE port of Zip. We'd like to do one eventually, but only if time permits, and it has been on hold for more than eight(!) years. Don't hold your breath, eh?
They are...now.
The encryption key in Zip is 96 bits long, which originally required an export license to export from the US, even though the encryption code was imported into the US in the first place. We didn't have one.
In January 2000, the Bureau of Export Administration (BXA) of the US Department of Commerce relaxed its restrictions on the export of free encryption source code, so newer Info-ZIP releases do now include the full crypto sources. But compiled binaries that included encryption (as opposed to decryption-only) were still restricted, so our main US distribution site continued to carry only non-encrypting Zip binaries.
However, in June 2002, the newly renamed Bureau of Industry and Security (BIS, still part of the US Department of Commerce) further relaxed its restrictions on the export of object code compiled from free encryption source code. So ever since June 2003 (when we sent in our required export notification), we have distributed full encryption/decryption binaries along with the full source code--when we had them in the first place. Since we depend on others to provide binaries for many of the less-common architectures, and since some of those have not been updated since the restrictions were lifted, not all of our binaries support encryption. (If you have the ability to compile a newer version than what we currently provide, please contact us!)
Finally, note that the original encryption scheme used in all versions of Zip (as well as PKWARE's older products) is quite weak; see "A Known-Plaintext Attack on the PKZIP Stream Cipher" (also as gzip'd PostScript) by Eli Biham and Paul C. Kocher. Recent versions of PKZIP and WinZip include stronger AES encryption, and PGP/GnuPG have provided strong encryption for many years.
For self-extracting archives such as the one used in the example above, simply copy or move it into the directory of your choice, cd into that directory and run the self-extracting archive:
unz552xN // extract contents of unz552xN.exe
// archive to the current directory
This can be done either from a command-line prompt or via a "Run This" menu item (e.g., in Windows). If the archive doesn't run, either you don't have enough memory available (try exiting to plain DOS if running a graphical shell) or you didn't download the archive properly (see FAQ #1).
After successful extraction, read the enclosed unzip.txt file for explicit directions on using the newly extracted unzip.exe program. Then use it! For example:
unzip -t foo.zip // test the archive "foo.zip" (see
// unzip.txt for other examples)
Note that currently all but three ports are command-line only! The three exceptions are the Macintosh port (MacZip, with integrated Zip support), the Windows 3.x/9x/NT port (WiZ, also with integrated Zip support), and the Windows CE/NT port (Pocket UnZip).
Alas, we're really slow and still don't support the creation of multi-volume (or multi-disk) archives. That's at the top of the to-do list, however. Look for UnZip 6.0 and Zip 3.0 someday, but no more promises as to when. (Actually, the whole zipfile format is showing its age; arguably it would be better to start over from scratch than to retrofit support for PKWARE's broken multi-part scheme onto the existing code base, but that's even more work.)
Extraction is currently supported, however, albeit in a crude manner. First concatenate all of the pieces together (in order!), using whatever command is appropriate for your system:
copy/b part1.zip+part2.zip+etc.zip monster.zip // under DOS, OS/2 or Win*
cat part1.zip part2.zip etc.zip > monster.zip // under Unix
Then use Zip's "zipfix" option to patch up the big archive (optionally get rid of all of the little pieces first if you're short on disk space):
zip -F monster.zip // fix up the concatenated archive
The archive is now a large but perfectly ordinary zipfile (unless it's bigger than 2 GB, in which case see below); extract, test or list its contents just like you normally would.
This is not yet supported by UnZipSFX. It may be supported in a future release, but no promises. (Adding functionality to run a custom install program is pretty simple, however; grab the sources and roll your own!)
The procedure is basically described in the UnZipSFX man page. First grab the appropriate UnZip binary distribution for your target platform (DOS, Windows, OS/2, etc.), as described above; we'll assume DOS in the following example. Then extract the UnZipSFX stub from the distribution and prepend as if it were a native Unix stub:
unzip unz552x3.exe unzipsfx.exe // extract the DOS SFX stub
cat unzipsfx.exe yourzip.zip > yourDOSzip.exe // create the SFX archive
zip -A yourDOSzip.exe // fix up internal offsets
That's it. You can still test, update and delete entries from the archive; it's a fully functional zipfile. Note that Zip versions prior to 2.2 will emit a warning about a "preamble of xxx bytes." This can be ignored.
You may or may not be hosed. Info-ZIP's utilities use the normal C library functions to read and write files; those functions, in turn, depend on the operating system to provide file-system support. Plain DOS, even the DOS 7.0 at the heart of Windows 9x, does not support VFAT or FAT32 long filenames. And writing very low-level, OS-dependent code to support one system violates Info-ZIP's goal of maximal portability (even if most of the necessary code is already freely available in Linux and elsewhere, though possibly with incompatible licenses).
So while Info-ZIP's Win32 versions do support long filenames in Win9x DOS boxes, they don't even run under plain DOS. And the DOS versions mostly don't support long filenames, with one exception: if UnZip is compiled with the free djgpp 2.x compiler (now part of Cygwin?), it will support long filenames under Windows 95/98/ME (not NT/2000) or short filenames under plain DOS. The currently available 32-bit executable in unz552x3.exe was compiled with djgpp 2.x.
Your best bet, therefore, is to try Chris Jones' LFNDOS VFAT/FAT32 device driver for DOS, which is somewhat similar to the OS/2 HPFS device drivers already available for DOS (e.g., HPFS-Access, Amos, etc.). We have not tested it ourselves, but it sounds like it does exactly what's needed. Thanks to Joe Forster, Bruno Binet and Jim O'Dell for the tip.
Other possibilities include Duncan Murdoch's DOSLFNBK and LFNSORT utilities. For archiving only (i.e., not extracting), J. Tigchelaar's LDZIP can be used to back up long filenames under plain DOS. (Note that DOS 7.1 or later is required to support the newer FAT32 partitions.)
Yup, there are recursion bugs in the Win32 port of both Zip 2.1 and 2.2. The documented way in 2.1 is this:
zip -r foo.zip . -i *.exe // doesn't recurse as expected under Windows 9x, NT
This is what actually works:
zip -r foo.zip * -i *.exe // recursively archive all *.exe files
This bug was fixed in Zip 2.2, but that version in turn has a bug in its new -R option:
zip -R foo.zip *.exe // doesn't recurse as expected
For now, the previous method (using -r and -i) will work. The -R bug is fixed in 2.3. We apologize for the inconvenience.
ZipNote has provided this capability almost since it was created, but the interface is very crude and not necessarily as well documented as it should be. Here's an example showing how it works (which also ties in to the previous question). First, redirect ZipNote's output to a file that you can subsequently edit:
zipnote invalid-dirseps.zip > invalid-dirseps.txt // create renaming template
ZipNote's output (in invalid-dirseps.txt) will look something like this:
@ invalid\subdir\oldname.1
@ (comment above this line)
@ invalid\subdir\oldname.2
@ (comment above this line)
@ invalid\othersubdir\oldname.3
@ (comment above this line)
@ (zip file comment below this line)
Next, edit the output file--but in place of file comments, add lines specifying new filenames, using the special "@=" syntax:
@ invalid\subdir\oldname.1
@=valid/subdir/new.1
@ (comment above this line)
@ invalid\subdir\oldname.2
@=valid/subdir/newname.much-longer.2
@ (comment above this line)
@ invalid\othersubdir\oldname.3
@=valid/other/short.3
@ (comment above this line)
@ (zip file comment below this line)
Note that this particular example changes all backslashes to forward slashes, shortens two filenames (oldname.1, oldname.3) and one subdirectory name (othersubdir), and lengthens one filename (oldname.2). There are no particular limits on zipfile filenames when renaming with ZipNote (other than the 65,535-character limit on filename lengths), but note that the target filesystem may have much more stringent limits (e.g., 1024-character maximum path length, a list of invalid filename characters, etc.).
When you're done editing the output file, use ZipNote once more to apply it to the zipfile. (You may wish to do this to a copy of the archive, just in case something goes wrong...)
zipnote -w copy-of-invalid-dirseps.zip < invalid-dirseps.txt // rename zipfile filenames
That's it--no recompression required. Note, however, that ZipNote does make a temporary copy of the zipfile while working (in case it's interrupted), so you will briefly need room for the extra temporary copy in addition to any copy you may have made.
Yes, at least the UnZip 5.4 DLLs and Zip 2.3 DLLs (and later versions).
Note that paths specified as arguments must be in zipfile format--that is, forward slashes ("/"), no drive letters, etc.
The UnZip DLL is believed to be thread-safe. The Zip DLL is not.
UnZip's error codes are documented in its man(ual) page, unzip.txt (which is included with all official distributions), and are defined as follows (on all platforms but VMS):
| UnZip | |
|---|---|
| value | meaning |
| 0 | Normal; no errors or warnings detected. (There may still be errors in the archive, but if so, they weren't particularly relevant to UnZip's processing and are presumably quite minor.) |
| 1 | One or more warning errors were encountered, but processing completed successfully anyway. This includes zipfiles where one or more files was skipped due to unsupported compression method or encryption with an unknown password. |
| 2 | A generic error in the zipfile format was detected. Processing may have completed successfully anyway; some broken zipfiles created by other archivers have simple work-arounds. |
| 3 | A severe error in the zipfile format was detected. Processing probably failed immediately. |
| 4 | UnZip was unable to allocate memory for one or more buffers during program initialization. |
| 5 | UnZip was unable to allocate memory or unable to obtain a tty (terminal) to read the decryption password(s). |
| 6 | UnZip was unable to allocate memory during decompression to disk. |
| 7 | UnZip was unable to allocate memory during in-memory decompression. |
| 9 | The specified zipfile(s) was not found. |
| 10 | Invalid options were specified on the command line. |
| 11 | No matching files were found. |
| 50 | The disk is (or was) full during extraction. |
| 51 | The end of the ZIP archive was encountered prematurely. |
| 80 | The user aborted UnZip prematurely with control-C (or similar) |
| 81 | Testing or extraction of one or more files failed due to unsupported compression methods or unsupported decryption. |
| 82 | No files were found due to bad decryption password(s). (If even one file is successfully processed, however, the exit status is 1.) |
Zip's error codes (and those of ZipSplit, ZipNote, and ZipCloak) are documented only in the ziperr.h source file. They are defined as follows:
| Zip | |
|---|---|
| value | meaning |
| 0 | Normal; no errors or warnings detected. |
| 2 | The zipfile is either truncated or damaged in some way (e.g., bogus internal offsets) that makes it appear to be truncated. |
| 3 | The structure of the zipfile is invalid; for example, it may have been corrupted by a text-mode ("ASCII") transfer. |
| 4 | Zip was unable to allocate sufficient memory to complete the command. |
| 5 | Internal logic error. (This should never happen; it indicates a programming error of some sort.) |
| 6 | ZipSplit was unable to create an archive of the specified size because the compressed size of a single included file is larger than the requested size. (Note that Zip and ZipSplit still do not support the creation of PKWARE-style multi-part archives.) |
| 7 | The format of a zipfile comment was invalid. |
| 8 | Testing (-T option) failed due to errors in the archive, insufficient memory to spawn UnZip, or inability to find UnZip. |
| 9 | Zip was interrupted by user (or superuser) action. |
| 10 | Zip encountered an error creating or using a temporary file. |
| 11 | Reading or seeking (jumping) within an input file failed. |
| 12 | There was nothing for Zip to do (e.g., "zip foo.zip"). |
| 13 | The zipfile was missing or empty (typically when updating or freshening). |
| 14 | Zip encountered an error writing to an output file (typically the archive); for example, the disk may be full. |
| 15 | Zip could not open an output file (typically the archive) for writing. |
| 16 | The command-line parameters were specified incorrectly. |
| 18 | Zip could not open a specified file for reading; either it doesn't exist or the user running Zip doesn't have permission to read it. |
On VMS, both UnZip's and Zip's error codes are translated into a range appropriate to VMS. 0 (success) is translated to 1 (VMS success), and all others are multiplied by 16 and added to 0x7fff0000 plus a final offset of 0, 2 or 4 depending on whether the return code is a warning, a "normal" error, or a severe (fatal) error, respectively. For example, return code 5 becomes 0x7fff0000 + 16*5 + 4 = 0x7fff0054 = 2147418196.
According to strict interpretation of the 2.x zipfile specification (but see the PKZIP 4.50 comments below), the following limits apply to all zipfile archives:
| statistic | limit | comments |
|---|---|---|
| number of files | 65,536 | This is not a "hard" limit, and Zip 2.2 will happily store more than 64K files (we've tested with 70,001); UnZip 5.41 and later will extract them again. (Earlier releases will not.) Note that Zip will first store in memory the path/filename and various parameters for every file that will be in the final archive; the actual limit on the number of files may be determined by the amount of RAM and/or virtual memory available on the system. Also note that 16-bit DOS versions of Zip are limited to around 16,000 files. |
| uncompressed size of a single file | 4 GB | This is also not a hard limit, in that the deflate algorithm used in all recent releases has its own "end of stream" marker. Some file systems and/or C libraries may not support files this big, however, and there are other zipfile limits (see below) that may have an impact. However, we do have a report that a user of the Win32 versions of Zip and UnZip succeeded in compressing and extracting a 7 GB database file. (The only reported oddity was in listing the archive's contents; UnZip has no way to know that the true file size is bigger than what the zipfile directory reports.) |
| compressed size of a single file | 4 GB | In practice, the real limit may be 2 GB on many systems, due to UnZip's use of the fseek() function to jump around within an archive. Because's fseek's offset argument is usually a signed long integer, on 32-bit systems UnZip will not find any file that is more than 2 GB from the beginning of the archive. And on 64-bit systems, UnZip won't find any file that's more than 4 GB from the beginning (since the zipfile format can only store offsets that big). So the last file in the archive can potentially be arbitrarily large (in theory, anyway--we haven't tested this), but the combined total of all the rest must be less than 2 GB or 4 GB, respectively. |
| total size of archive | 256 TB | While the only theoretical limit on the size of an archive is given by (65,536 files x 4 GB each), realistically UnZip's random-access operation and (partial) dependence on the stored compressed-size values limits the total size to something in the neighborhood of 2 to 4 GB. This restriction may be relaxed in a future release. (On 64-bit IRIX with the native compiler, the options "-mips4 -64" or "-mips4 -64 -ipa" [for both compiling and linking] may help. "-ipa" is reported to generate incorrect code sometimes, however.) |
| maximum path/filename length | 64 KB | Zipfiles have essentially no limits on the length of pathnames (or on the depth of directory trees); the actual limits will be imposed by the file system on which the archive was created. DOS and its derivatives (Windows, OS/2, etc.) generally limit paths to 256 characters or less; Unix systems typically have a 1024-character limit. Some CD-ROM file systems have an 8-level subdirectory limit. |
Note that there are other limitations of the zipfile format beyond its dependence on 16-bit and 32-bit fields. These include its weak encryption, poorly designed "extra field" capability, poorly designed "multi-disk" support, mediocre robustness, support for streaming encoders only as an afterthought, low-precision timestamps (two-second granularity), lack of cross-timezone support (i.e., Universal Time) except as a third-party add-on, lack of any support for "solid" packing of small files, lack of support for alternate character sets (e.g., EBCDIC) and encodings of international characters (e.g., UTF-8), unnecessary redundancy, and merely acceptable (but no longer outstanding) compression efficiency. All of these things suggest that it's time for a brand-new format, not just a few more patches on an aging standard. (And no, we're not volunteering, either--although we have discussed what we consider some of the requirements for such a new format.)
Also note that in August 2001, PKWARE released PKZIP 4.50 with support for large files and archives via a pair of new header types, "PK\x06\x06" and "PK\x06\x07". So far these headers are undocumented, but most of their fields are fairly obvious. We don't yet know when Zip and UnZip will support this extension to the format. In the short term, it is possible to improve Zip and UnZip's capabilities slightly on certain Linux systems (and probably other Unix-like systems) by recompiling with the -DLARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 options. This will allow the utilities to handle uncompressed data files greater than 2 GB in size, as long as the total size of the archive containing them is less than 2 GB. (The operating system also must have support for large files; for Linux, this involves the kernel [2.4 or later], the file system [at least Reiser and ext2 are supported], the C library [glibc 2.x], and possibly other file utilities [ls, rm, etc.] and the shell itself [bash, tcsh, etc.] if redirection is involved.)
There have been a few over the years. This table was created in August 2001 and last updated in May 2005. It is probably not 100% complete (particularly with respect to very old bugs), but it's close:
| program | platform | nature of bug |
|---|---|---|
| Zip 2.0.1 | any Unix | With Zip 2.0.1's -y option, symbolic links got stored as empty files--i.e., all knowledge of the file to which the link pointed was lost within the archive. This is fixed in version 2.1. |
| Zip 2.x | OS/2 3.x? | There was some bug involving updating archives (-u and -f options) on a networked HPFS386 partition, wherein part of the zipfile would be filled with zeros instead of the actual compressed data and header info. We don't recall the exact details, but an OS/2 fixpak is/was available to take care of the problem. (This was not a Zip bug, per se.) |
| Zip (all versions) |
Solaris, AIX, Red Hat Linux, others? |
Creating zipfiles on NFS file systems under Red Hat 6.x could result in silent corruption. This was a known bug in Solaris (Sunsolve ID 4071076), AIX (IBM APAR IY06322) and possibly other Unixen that seems to have been exacerbated by Red Hat's knfsd. It affected many archivers and other programs, and it could be fixed only by patching the NFS server. |
| Zip 2.0 through Zip 2.3 |
all |
When compiled with either BIG_MEM or MMAP defined (MMAP
overrides BIG_MEM if both are defined), Zip will
silently corrupt
stored (uncompressed) files when forced via either
the -0 ("store") or -n ("don't compress these suffixes")
options. Because the stored CRC-32 value is consistent with
the corrupted data, testing with UnZip will not expose the
error; only extraction and byte-for-byte comparison with the
original files will. This has now been
confirmed to be a long-standing bug in Zip itself
(within zipup.c only, not deflate.c). It does not
affect files that are stored due to small size or
incompressibility; these files use the code path in deflate.c.
Thus any of the following workarounds will suffice:
|
| Zip 2.3 and earlier |
all | HexView reported a buffer-overrun vulnerability (CVE-2004-1010) in Zip 2.3 related to deep directory paths, which could potentially lead to local privilege escalation (e.g., in the case of automated, Zip-based backups by a privileged account). We believe this bug affects all previous versions of Zip, as well, and most or all supported platforms. See also Secunia's advisory. This is fixed in version 2.31. (Thanks to Ulf Harnhammar and AusCERT's Matthew Aburn for the pointers.) |
| UnZip 5.42 and earlier |
virtually all | All versions of UnZip through 5.42 have a directory-traversal security vulnerability that allows them to unpack files in unexpected places. Specifically, if an archive contains files with leading "/" characters (i.e., relative to the top-level/root directory) or with ".." components ("previous directory level"), UnZip will unpack the files in the indicated locations, possibly creating directory trees in the process--and, if the -o ("overwrite") option is given, quietly destroying existing files outside the intended directory tree. This is fixed in version 5.50, and a patch (slight overkill, but apparently effective) is available on the Bugtraq page that reported the problem. (Thanks to Anya Berdichevskaya for the pointer.) |
| UnZip 5.50 and earlier |
virtually all | All versions of UnZip through 5.50 have a pair of directory-traversal vulnerabilities, both somewhat subtler than the original one (see above). The first one (CVE-2003-0282) involves placing one or more invalid characters between a pair of dots; the bogus characters are filtered out, leaving a ".." sequence that is used without further checks during extraction. The second involves the use of a quoted "/" character, which could be used either to convert a harmless ".." sequence into a harmful one or to create absolute (leading-"/") paths. These are fixed in version 5.51. (Thanks to jelmer and ITO Tsuyoshi for reporting them.) |
| UnZip 5.50 and earlier |
all | All versions of UnZip through 5.50 have a filename-mismatch vulnerability whereby files can be extracted with paths and names other than those that appear in archive listings. This is because UnZip uses the zipfile's central directory for listing files (and for matching user-specified filenames for extraction), but it uses the local file headers during the actual extraction process itself. Ordinarily the local and central filenames match, but an attacker could modify the names (and paths) in the local headers in order to cause files to be created in unexpected locations. In effect, this is yet another (fourth!) directory-traversal variant. This is fixed in version 5.51. (Thanks to Jan Echternach and John D. Hardin for reporting this.) |
| UnZip 5.50 and earlier |
Unix, BeOS, Atari, AOS/VS |
All versions of UnZip through 5.50 have a symlink-traversal vulnerability whereby extracted files can overwrite files in unexpected directories if appropriate directory-symlinks are extracted first. Yes, this is a fifth directory-traversal variant. This is fixed in version 5.51. (Thanks to Jan Echternach for reporting this.) |
| UnZip 5.50 | 16-bit ports (e.g., DOS) |
For all ports using 16-bit integers, textmode output (-a or -aa options) is broken in such a way that half of the output-buffer chunks are silently skipped. Because the bug is located in the output routine after the CRC check has been carried out (because there isn't any way to know the CRC for the text-converted data), it is not detected by any built-in consistency check. (Note that the more common 32-bit and 64-bit UnZip ports are not affected.) The workaround is to disable 64-bit deflate support when compiling 16-bit UnZip ports (define NO_DEFLATE64). This is fixed in version 5.51. |
| UnZip 5.51 and earlier |
Unix only | Albert Puigsech Galicia noted that one of UnZip's backup-related features, the restoration of file permissions including UID and GID bits, could constitute a privilege-escalation vulnerability (CVE-2005-0602) insofar as (1) UnZip doesn't emit a warning when restoring such bits, and (2) it's the default behavior in version 5.51 and earlier. This is fixed in version 5.52: the new -K option must be given explicitly in order to restore UID, GID and sticky bits. |
| UnZip 5.51 and earlier |
all | c0ntex reported a buffer-overrun vulnerability (CVE-2005-4667) in UnZip 5.51 related to very long (command-line) zipfile names, which theoretically could lead to local privilege escalation (e.g., in the case of automated, UnZip-based unpacking of user-specified archive names by a privileged account--not a terribly likely scenario). We believe this bug affects all previous versions of UnZip, as well, and most or all supported platforms. (It may also affect other tools, including some shells and gdb itself.) This is fixed in version 5.52. |
| UnZip 5.52 and earlier? |
Unix only? | Imran Ghory reported that the Unix port of UnZip has a race-condition vulnerability (CAN-2005-2475), whereby a local attacker could change the permissions of the user's files during unpacking. (Reported on LWN.) One workaround is to "ensure that any directory which is being used by unzip to decompress files is writeable only by the user"; another is to "set the sticky bit on the directory's permissions." This will be fixed in version 6.00 for platforms that have the fchmod() system call. |
| WiZ 5.02 and earlier? |
Windows | Chad Loder of Rapid7 discovered a crash bug and potential security vulnerability in WiZ, involving very long filenames inside archives. This problem does not appear to affect any of Info-ZIP's command-line tools or MacZip. See Rapid7's advisory for test archives and subsequent links, including CERT and CVE. This is fixed in version 5.03. |
No--unless UnZip is compiled with USE_ZLIB defined and the relevant version of zlib has the bug (i.e., any version of zlib before 1.1.4; check UnZip with "unzip -v"). The double-free bug affected only the version of inflate() in zlib; UnZip's version is not vulnerable, and Zip does not use inflate(). (Thanks to Mark Adler for verifying this.)
It's a bit late to be worrying about that now... But since you asked:
It depends a bit on how you use Zip and UnZip, but by and large there shouldn't be any problems. UnZip displays only two digits of the year when listing files (in most formats), so if you take that output and sort on the year field, it will fail. Older versions (5.3 and earlier, possibly also 5.31) would print "100" instead of "00" for the year 2000; this is fixed in 5.32 and later. Internally it uses DOS-format dates by default (no problems until 2108; i.e., 128 years after 1 January 1980) and Unix-format dates where available (no problems until January 2038, when 231 seconds will have elapsed since 1 January 1970). You also have the option of displaying dates in yyyymmdd.hhmmss format (unzip -ZT) for sorting, if you wish.
Zip 2.1 had a -t option that was not Y2K-ized, but that was fixed in 2.2 and seems to have been the only problem.
Note that it's possible that some PC-based C compilers or libraries have Y2K bugs in them that would affect Zip and UnZip. The Info-ZIP group has not explicitly tested any compilers for such problems. To check what compiler was used to create any of our pre-compiled executables, do "unzip -v" or "zip -v" with no other arguments.
Finally, note that this is not a warranty or certification of Y2K readiness. We believe the statements above to be completely truthful and accurate, but we accept no liability for errors in either the statements or the software. You don't pay for the code; don't expect us to do so, either.
The "shrink" compression method was encumbered by a patent ("LZW") until July 2004. Although it appeared that standalone unshrinking was not covered, the owner claimed otherwise in public statements, and the matter was never tested in court. (For what it's worth, the same algorithm was and is used in other utilities that have been included in every Linux and FreeBSD distribution that has ever shipped or been downloaded, and no one has ever complained about that. So the public statements were, most likely, simply the usual legal posturing. On the other hand, Info-ZIP had no particular desire to become the test case.)
Thus, by default, unshrinking was not enabled in some releases of Info-ZIP's distributed binaries (mostly newer ones). Those who wish to download older binaries or compile their own versions may still do so, or you can wait for UnZip 6.0, which will once again enable unshrinking by default. See UnZip's COPYING and INSTALL files for more information.
UnZip (and Zip, and all of the other Info-ZIP utilities) must be set up as a VMS foreign command, as noted in the README.VMS file included with our VMS distributions. Add some lines similar to the following to your LOGIN.COM file:
$ unzip == "$disk:[dir]unzip.exe"
$ zipinfo == "$disk:[dir]unzip.exe ""-Z"""
...where "disk" and "dir" refer to the true disk and directory where unzip.exe is located. The "$" before the disk name is important; i.e., don't delete it. All of the quotes in the ZipInfo line are necessary, too, so don't delete any of them, either.
Finally, run UnZip just as on any other system (see FAQ #2). Do not type "run" before the command.
You need to upgrade your copy of Internet Explorer to version 4.0 or later. There is a bug in older versions.
The root cause is a longstanding bug in Windows NT, Windows 95/98, and Windows CE. If an archived file was last modified during Daylight Savings Time (a.k.a. Summer Time) and is being extracted during Standard Time--or vice versa--Windows applies the current timezone offset (including DST) to the extracted file instead of using the offset that was applicable on the date the file was created or otherwise modified. This results in an off-by-one-hour problem in some extracted files, especially around April and October when locales that observe DST typically switch between it and Standard Time. (Aside: You can see the bug in action, completely independent of Zip and UnZip, by saving a Windows directory listing just before the switch and comparing it with one taken just after the switch. All file times will appear to shift by an hour.)
We addressed this problem in 1997 for UnZip 5.3, and while there may have been some lingering oversights in that series, the UnZip 5.4x series should be completely fixed. However, if and when the Windows bug is ever fixed, it's possible that Info-ZIP's workaround will recreate the bug in reverse. To our knowledge, this has not yet happened.
Two reasons:
This is a known bug with HPFS386-based network drives (LAN Server 4.0 or Warp Server), and IBM has not provided a patch. UnZip 5.2 and later have a work-around for the problem, however. (Note that the same bug will affect any program that uses the DosSetPathInfo() call.)
Short answer: because that's how they're stored in the zipfile, and backslashes ('\') are regular filename characters, not directory separators.
Longer answer: older versions of WinZip (and, no doubt, some other clone zippers) stored filenames using backslashes as directory separators in violation of PKWARE's appnote, which specifies that forward slashes ('/') should be used. Newer versions of WinZip correct that bug, so if you created the archive in question, you should upgrade. If someone else did, you should ask them to upgrade.
There is no capability in Unix UnZip to treat backslashes as directory separators (since they're perfectly acceptable filename characters, just like colons, quotes, and pretty much everything other than forward slashes), so if you want to extract the archive as a subdirectory tree without hacking the source code, you'll need to rename the archive entries. See the next item for more information about that.
This is almost certainly an error in the Symantec "emergency boot disk," which, according to a Symantec response on their German web site, has an outdated virus signature file. The standard version 5.0 of Norton AV (for Windows 95/98) does not report any such thing. Many thanks to Michael Kilby for tracking this down.
If the password was very short (i.e., essentially useless), there are various brute-force password-crackers available. If it was more than 8 or 10 characters and not restricted to a small subset of ASCII (e.g., not just the 26 lowercase letters), it might still be recoverable via a known-plaintext attack (see above). Either way, the comp.compression FAQ list is the place to start looking.
There is an optimization bug in the native (non-GNU) HP C compiler for HP-UX 10.20 that breaks Zip's encryption code and UnZip's decryption code. Recompile crypt.c with optimization turned off (no -O or +O2 option) or turned down to the lowest level (+O1). Note that this bug affects both decryption of zipfiles created elsewhere and encryption of zipfiles created on HP-UX (i.e., the latter cannot be decoded on other systems).
Our original mailing lists died several years ago, thanks both to the ever-shifting sands of mail servers and to spammers. We may set up new lists on SourceForge at some point, but in the interim, a web-based forum, with both bug-reporting and discussion areas, has been set up. (The older forum at QuickTopic is also available in read-only mode; click the "printer-friendly" link to see the archived, non-spam messages in compact form.)
Zip-Bugs, the internal mailing list for the core development team, was shut down in August 2003 in favor of a web-based contact form. As convenient as the real e-mail address was to everyone involved, it turned out to be equally convenient to the masses of header-forging viruses and spam messages propagating across the Internet. Once the noise level exceeded the convenience factor, it had to go.
When they're ready. Watch these web pages, subscribe to the mailing list(s), and/or check the freshmeat pages for news. Don't send us "bug reports" about it.
That said, as of mid-2006, Zip 3.0 and UnZip 6.0 are coming along and should be released sometime in the first half of 2007.
Yes. See our new(er) open-source, BSD-style license for details.
Note that it applies only to our more recent releases (starting in November 1999): Zip 2.3, UnZip 5.41, WiZ 5.01, MacZip 1.04, and subsequent updates. All older releases are still covered by our old COPYING file (UnZip) or the README file in official Zip distributions.
Yes, Sherlock, we know. It was intentional. It was humor. Ar ar. Now go away.
![[Info-ZIP]](images/InfoZIP-gold-sml.png){kind=small}
Return to the Info-ZIP Home Page.