On Wed, 15 Nov 2023 20:10:53 GMT, Eirik Bjorsnos <d...@openjdk.org> wrote:
>> 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. > > Eirik Bjorsnos has updated the pull request incrementally with one additional > commit since the last revision: > > Extract ZIP64_BLOCK_SIZE_OFFSET as a constant Thank you for your efforts here Eirik. I am OK with the proposed changes. We have completed internally our Mach5 runs and thanks to Jai, we have been able to exercise a build against a large internal repository of jars I would like to suggest that we hold off until we fork for JDK 23 to push this (as we are going to do for my outstanding CEN validation checks) so that we are allowing for more time to catch the unexpected hiccup ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/12524#pullrequestreview-1753604135
