On Sun, 15 Sep 2024 13:11:26 GMT, Lance Andersen <lan...@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
