RFR: 8340553: ZipEntry field validation does not take into account the size of a CEN header [v2]

[Lance Andersen]

On Thu, 17 Oct 2024 19:29:16 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>>> I had thought about that and decided to keep the changes as they are. I am not opposed to revisiting this in a follow on PR. Any additional changes would require more javadoc updates to address the overall change in validation.
>>> 
>>> So after we fork JDK 24, happyt to revisit.
>> 
>> If the route we're taking ends up with having `ZipEntry` manage its own invariant here, then I'm only lukewarm to including this solution in 24 which only takes us half way and has weaker validation than what's already in place in `ZipOutputStream`.  There would be less API churn if we hold our breath here and do it "right" in a single release.
>> 
>> But that's my subjective opinion, it's understandable and fine that others see it differently.
>
>> But that's my subjective opinion, it's understandable and fine that others see it differently.
> 
> Again, I understand your suggestion and will give it some  additional thought. The original intent was to address the incorrect max value that each of the 3 fields were being validated against, which has been there since at least JDK 1.3.
>  
> Overall this is a corner case and out of a search of 90,000+ jars, only 520 CEN Headers were encountered with a size between 500-1000 bytes, all other entries were < 500 bytes.

Ok,  I revised ZipEntry to incorporate your suggestion.   I kept the validation in ZipOutputStream::putNextEntry in the unlikely event ZipEntry is extended based on a suggestion from Jai.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1806452806