RFR: 8313765: Invalid CEN header (invalid zip64 extra data field size)

Sergey Bylokhov serb at openjdk.org
Mon Aug 14 19:08:07 UTC 2023


On Mon, 14 Aug 2023 18:41:26 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > I am not understanding your point. There is a specific order for the Zip64 fields based on which fields have the Magic value. the spec does also not suggest that an empty Zip64 extra field can be written to the CEN when there is a Zip64 with data written to the LOC.
> 
> Yes, there is a specific order of fields that should be stored in the extended block if some of the data in the "body" is negative. But as you pointed out in this case the empty block or block bigger than necessary to store the size/csize/locoff is not prohibited by the spec. For example, take a look at the code in the [ZipEntry](https://github.com/openjdk/jdk/blob/c132176b932dd136d5c4314e08ac97d0fee7ba4d/src/java.base/share/classes/java/util/zip/ZipEntry.java#L553) where we accept any size of that block and just checked that it has required data in it.
> 
> If you disagree then point to the part of the spec which blocks such sizes.

This is how it is implemented by the "unzip"
https://github.com/madler/zlib/blob/04f42ceca40f73e2978b50e93806c2a18c1281fc/contrib/minizip/unzip.c#L1035C68-L1035C76 , the dataSize is accepted as is.

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

PR Comment: https://git.openjdk.org/jdk/pull/15273#issuecomment-1677908114


More information about the nio-dev mailing list