RFR: 8336025: Improve ZipOutputSream validation of MAX CEN Header field limits [v2]

[Eirik Bjørsnøs]

On Sun, 15 Sep 2024 13:11:26 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review the following PR which addresses that ZipOutputStream should validate the CEN header fields similar to what was done via [JDK-8316141](https://bugs.openjdk.org/browse/JDK-8316141)
>> 
>> As part of this change, the javadoc for ZipEntry has been updated to indicate that the CEN Header(46 bytes) + entry name length + comment length + extra data length must not exceed 0xfffff.
>> 
>> Mach5 tiers 1-3 runs were clean.  The zip and jar JCK tests also continue to pass
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update @link ->@linkplain

I'm curious why the combined header length validation is being placed so late. In general I would assume failing fast is better?

Also, since the combined header length clause applies to "any directory record", it also applies to LOC?

So why is this happening late in `writeCEN`, as opposed to early in `putNextEntry`?

Edit: I'm aware that moving it to `putNextEntry` means you probably need to repeat it in writeCEN, just in case the `ZipEntry` was updated meanwhile. 

Some comments inline.

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

PR Review: https://git.openjdk.org/jdk/pull/21003#pullrequestreview-2306219878