[PATCH] Unzip fails without optional extended local header signature

[Michael Gray]

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

address@hidden

gzip_unzip_exthdr_nosig_bugfix.patch
Description: Binary data