On Thu, 17 Oct 2024 19:29:16 GMT, Lance Andersen <lan...@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
