RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64 ZIP files [v12]
Eirik Bjørsnøs
eirbjo at openjdk.org
Mon Jan 22 14:37:35 UTC 2024
On Tue, 16 Jan 2024 14:55:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:
> I think the only role that a zip64 block should play when we are deciding how to parse a data descriptor is whether or not the entry has zip64 extra field set (the header id value of the extra field). Does that sound reasonable?
Are you suggesting that we ONLY look for the presence of a Zip64 (tag 0x1) extended field? Meaning we should ignore the following:
- The values of the 'compressed size' and 'uncompressed size' fields in the LOC header
- The contents/fields in the data block in the Zip64 header
The purpose of this check is to determine wheter the entry "is in the ZIP64 format", to use parlance from `APPNOTE.TXT`. The reason stronger validation was added was to avoid false positives, meaning an entry would be interpreted as "in the Zip64 format", even when that was not the intention of the producer. Some of this validation was on my initiative, but I think maybe some was in response to concerns raised in review.
If we ignore the 'uncompressed size' and 'compresssed size' fields, then if a LOC has both of these set to zero and has a Zip64 extended field, then we'll intepret this as "in the Zip64 format", even though no field is marked using the Zip64 magic value `0xFFFFFFFF`.
I think I would be fine with dropping inspection of the Zip64 contents (as there are probably efforts underway to add validation of LOC Zip64 fields similar to the recently added CEN validation).
But I'm a bit worried that ignoring the LOC values will make us parse some data descriptors using 8 bytes, when the producer did in fact not intend to use the Zip64 format. (The Zip64 field just came through some kind of "pollution" or unintended copying.
A natural way to implement Zip64 parsing is to only look at the extended field if at least one of the relevant LOC headers are `0xFFFFFFFF`, otherwise one can short-circuit and assume there is no Zip64 field.
@LanceAndersen Do you have a cent or two to spare?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1461951695
More information about the core-libs-dev
mailing list