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

[Lance Andersen]

On Mon, 14 Aug 2023 17:59:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > It's unfortunate that there are tools and plugins in the eco system that have these issues. I think you've got the right balance here, meaning tolerating a zip64 extra block with a block size of 0 and rejecting corrupted extra blocks added by older versions of the BND plugin.
> 
> I think I already asked this question, but it disappeared in the latest PR: Why our code has an assumption that the extended block has some kind of limitation of the size, like 9,16,24,28, there are no such limitations in the zip specification: https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT
> 
> ```
>      4.5.3 -Zip64 Extended Information Extra Field (0x0001):
> 
>       The following is the layout of the zip64 extended 
>       information "extra" block. If one of the size or
>       offset fields in the Local or Central directory
>       record is too small to hold the required data,
>       a Zip64 extended information record is created.
>       The order of the fields in the zip64 extended 
>       information record is fixed, but the fields MUST
>       only appear if the corresponding Local or Central
>       directory record field is set to 0xFFFF or 0xFFFFFFFF.
> 
>       Note: all fields stored in Intel low-byte/high-byte order.
> 
>         Value      Size       Description
>         -----      ----       -----------
> (ZIP64) 0x0001     2 bytes    Tag for this "extra" block type
>         Size       2 bytes    Size of this "extra" block
>         Original 
>         Size       8 bytes    Original uncompressed file size
>         Compressed
>         Size       8 bytes    Size of compressed data
>         Relative Header
>         Offset     8 bytes    Offset of local header record
>         Disk Start
>         Number     4 bytes    Number of the disk on which
>                               this file starts 
> 
>       This entry in the Local header MUST include BOTH original
>       and compressed file size fields. If encrypting the 
> ```
> 
> It probably comes from the Wiki page: https://en.wikipedia.org/wiki/ZIP_(file_format) but it is not a spec.
> 
> Note the spec also says that an extended block should be created **at least** in this case
> 
> ```
>      " size or
>       offset fields in the Local or Central directory
>       record is too small to hold the required data,
>       a Zip64 extended information record is created."
> ```
> 
> It does not say that the block cannot be empty or have any other size if all fields in the body of the zip file are correct/valid.

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.

If you have a zip which demonstrates an issue not addressed, Please provide an a test case, with the tool created the  zip and it be can looked at.

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

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