RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64 ZIP files

Eirik Bjorsnos duke at openjdk.org
Wed Mar 29 09:34:30 UTC 2023


ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the number of compressed or uncompressed bytes read from the inflater is larger than the Zip64 magic value.

While the ZIP format  mandates that the data descriptor `SHOULD be stored in ZIP64 format (as 8 byte values) when a file's size exceeds 0xFFFFFFFF`, it also states that `ZIP64 format MAY be used regardless of the size of a file`. For such small entries, the above assumption does not hold.

This PR augments ZipInputStream.readEnd to also assume 8-byte sizes if the ZipEntry includes a Zip64 extra information field. This brings ZipInputStream into alignment with the APPNOTE format spec:


When extracting, if the zip64 extended information extra 
field is present for the file the compressed and 
uncompressed sizes will be 8 byte values.


While small Zip64 files with 8-byte data descriptors are not commonly found in the wild, it is possible to create one using the Info-ZIP command line `-fd` flag:

`echo hello | zip -fd > hello.zip`

The PR also adds a test verifying that such a small Zip64 file can be parsed by ZipInputStream.

-------------

Commit messages:
 - Merge branch 'master' into data-descriptor
 - Zip64 extra field of a LOC header has 1-3 long components
 - Clarify comment for shouldIgnoreExcessiveExtraSize
 - Update test to use a Zip64 file produced using the zip command with the -fd flag
 - Add comment to explaining the setExtraSize and readZipInputStream methods and the zip64File field.
 - Add comment to the call site of hasZip64 extra
 - Improve the documentation of ZipInputStream.hasZip64Extra, explaining how the method is used and adding a reference to the APPNOTE.txt specification.
 - Make (2 * Short.BYTES) less magic my extracting a variable with a comment
 - Merge branch 'master' into data-descriptor
 - Validate that the Zip64 extra field is right sized (8, 16, 24 or 28 bytes). Add tests for excessive and invalid extra data sizes.
 - ... and 7 more: https://git.openjdk.org/jdk/compare/6d30bbe6...0633c807

Changes: https://git.openjdk.org/jdk/pull/12524/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12524&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303866
  Stats: 214 lines in 2 files changed: 212 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12524.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12524/head:pull/12524

PR: https://git.openjdk.org/jdk/pull/12524


More information about the core-libs-dev mailing list