Please review this PR which adds validation of the 'total entries' value when fetched from the 'ZIP64 End of Central Directory' header.
We should reject this value under the following conditions: 1. It is too large to fit within the specified CEN size (considering each CEN header encodes as at least 46 bytes each) 2. It is too large to create the `int[] entries` array safely (max value is `ArraysSupport.SOFT_MAX_ARRAY_LENGTH / 3`) I claim that condition 2 here is already implicitly validated by the current maximum CEN size validation. (A CEN encoding such a large number of entries would exceed the maximum CEN size a lot and would already be rejected) This change aims to protect the integrity of the implementation against specially crafted ZIP files. No sane ZIP tool will produce such files. Testing: This PR adds a test `EndOfCenValidation.shouldRejectBadTotalEntries` which exercises the first condition above. ZIP tests run locally. GHA results pending. ------------- Commit messages: - No need to check MAX_ENTRIES, since MAX_ENTRIES * 46 would exceed the MAX_CEN_SIZE anyhow - Test comment should be specific that this requires Zip64 - Improve ZipFile validation of Zip64 END headers Changes: https://git.openjdk.org/jdk/pull/21384/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21384&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8341625 Stats: 140 lines in 2 files changed: 137 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/21384.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21384/head:pull/21384 PR: https://git.openjdk.org/jdk/pull/21384
