I believe I've found a bug regarding the decompression of single-entry .zip files.
As per the Section V.C of the .ZIP File Format Specification (http://www.pkware.com/documents/casestudies/APPNOTE.TXT), data descriptors (called the extended local header in the gzip source) *may or may not* be preceded by a signature. Gzip always assumes this signature is present; if it is not, it reads the CRC and length values 4 bytes further into the file than it should, and the CRC and length checks fail even though the file is not corrupt. I've included a patch that works around the problem. First, it assumes that the signature *is not present*, as it's possible that the signature value is also a valid CRC, and no non-corrupt file should be rejected if it's CRC just happens to match the signature value. If the CRC or length check fails assuming the signature is not present, the signature is then checked for. If present, 4 more bytes of input are read, and the previously read values are shifted appropriately. The CRC and length checks then proceed as normal. Below is the text of the relevant text from the .ZIP spec: " Although not originally assigned a signature, the value 0x08074b50 has commonly been adopted as a signature value for the data descriptor record. Implementers should be aware that ZIP files may be encountered with or without this signature marking data descriptors and should account for either case when reading ZIP files to ensure compatibility. When writing ZIP files, it is recommended to include the signature value marking the data descriptor record. When the signature is used, the fields currently defined for the data descriptor record will immediately follow the signature. " -- Michael Gray mike...@gmail.com
gzip_unzip_exthdr_nosig_bugfix.patch
Description: Binary data
