RFR: 8377992: (zipfs) Align ZipFileSystem END header validation with the ZipFile implementation
Please review this PR which brings `jdk.nio.zipfs.ZipFileSystem` `END` header validation into behavioral alignment with the corresponding checks in `java.util.zip.ZipFile`. This brings two validation checks over to `ZipFileSystem`: * Rejection of END headers with a CEN size larger than `ArraysSupport.SOFT_MAX_ARRAY_LENGTH` (JDK-8272746) * Rejection of END headers with a total entry count which cannot fit within the CEN byte array (JDK-8341625) The test `test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java` is updated to to verify that ZIP files rejected by the `ZipFile` constructor are now also rejected by `ZipFileSystem.newFileSystem`. Tangentially, `ZipFileSystem.findEND` is updated to make `END.centot` a `long` instead of an `int`. This avoids a narrowing conversion which otherwise prevents validating a larger than Integer.MAX_VALUE number of CEN entries. Similar adjustments to `ZipFile` was done in JDK-8341625. `ZipFile.Source.initCEN` is updated with some minor code style / code comment changes to make side-by-side diffs less noisy. Additionally, validated `end.cenlen` and `end.centot` values are now consistently converted to `int` using `Math.toIntExact`. ------------- Commit messages: - Fix merge commit - Merge branch 'master' into zipfs-endofcen-validation - Realign comment whitespace - Use Math.toIntExact once in End::write - Align ZipFileSystem END header validation with the ZipFile validation Changes: https://git.openjdk.org/jdk/pull/29747/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29747&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377992 Stats: 85 lines in 3 files changed: 42 ins; 16 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/29747.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29747/head:pull/29747 PR: https://git.openjdk.org/jdk/pull/29747
On Mon, 16 Feb 2026 15:15:28 GMT, Eirik Bjørsnøs <eirbjo@openjdk.org> wrote:
Please review this PR which brings `jdk.nio.zipfs.ZipFileSystem` `END` header validation into behavioral alignment with the corresponding checks in `java.util.zip.ZipFile`.
This brings two validation checks over to `ZipFileSystem`:
* Rejection of END headers with a CEN size larger than `ArraysSupport.SOFT_MAX_ARRAY_LENGTH` (JDK-8272746) * Rejection of END headers with a total entry count which cannot fit within the CEN byte array (JDK-8341625)
The test `test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java` is updated to to verify that ZIP files rejected by the `ZipFile` constructor are now also rejected by `ZipFileSystem.newFileSystem`.
Tangentially, `ZipFileSystem.findEND` is updated to make `END.centot` a `long` instead of an `int`. This avoids a narrowing conversion which otherwise prevents validating a larger than Integer.MAX_VALUE number of CEN entries. Similar adjustments to `ZipFile` was done in JDK-8341625.
`ZipFile.Source.initCEN` is updated with some minor code style / code comment changes to make side-by-side diffs less noisy. Additionally, validated `end.cenlen` and `end.centot` values are now consistently converted to `int` using `Math.toIntExact`.
Hi Eirik, Thank you for your efforts here and overall the changes to ZipFile and ZipFS are fine. WRT the test, it is preferable that the ZipFS tests are added to open/test/jdk/jdk/nio/zipfs for now so that we have the specific tests co-located. At some point we may want to revisit our structure for zip and zipfs tests bu that would be separate from this PR ------------- PR Review: https://git.openjdk.org/jdk/pull/29747#pullrequestreview-3826848135
On Thu, 19 Feb 2026 16:04:34 GMT, Lance Andersen <lancea@openjdk.org> wrote:
WRT the test, it is preferable that the ZipFS tests are added to open/test/jdk/jdk/nio/zipfs for now so that we have the specific tests co-located.
The existing `EndOfCenValidation` test goes through some heroic efforts to create ZIP/ZIP64 files under reasonable size and efficiency constraints that provokes these edge-cases being tested. The reason I opted to expand the existing test with support for verifying `ZipFileSystem` was based on the following observations: * We want to ensure that validation for these cases is equivalent across APIs * Co-locating them avoids duplication of good amounts of intricate setup of test vectors Did you mean that we should copy this tests and maintain the copy separately in the `zipfs` area? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29747#issuecomment-3928397967
On Thu, 19 Feb 2026 16:34:55 GMT, Eirik Bjørsnøs <eirbjo@openjdk.org> wrote:
WRT the test, it is preferable that the ZipFS tests are added to open/test/jdk/jdk/nio/zipfs for now so that we have the specific tests co-located.
The existing `EndOfCenValidation` test goes through some heroic efforts to create ZIP/ZIP64 files under reasonable size and efficiency constraints that provokes these edge-cases being tested.
The reason I opted to expand the existing test with support for verifying `ZipFileSystem` was based on the following observations:
* We want to ensure that validation for these cases is equivalent across APIs * Co-locating them avoids duplication of good amounts of intricate setup of test vectors
Did you mean that we should copy this tests and maintain the copy separately in the `zipfs` area?
Understand WRT the zip creation logic. It can be easy to miss specific tests if they are not included in the primary test directory as there are times for example that you might only to need to run zipfs specific tests So you could create a utility class which is shared by the ZipFile or ZipFs test or take the easier route of having a copy of the code in each directory. I would probably error on the side of creating a utils directory and placing the specific shared code in a class there that is imported or extended... I will defer to you on your preference though ;-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/29747#issuecomment-3928618386
On Thu, 19 Feb 2026 17:12:23 GMT, Lance Andersen <lancea@openjdk.org> wrote:
So you could create a utility class which is shared by the ZipFile or ZipFs test or take the easier route of having a copy of the code in each directory.
I opted to extract the test vector setup and some shared constants into `jdk.test.lib.util.ZipUtils`. I retained a copyright year of 2023, 2026 for this one. I then copied `EndOfCenValidation` to ZipFS. Some cleanups applied first, such as extracting the method `verifyRejection` to handle the repeated `assertThrows`, `assertEquals` checks. While this does not eliminate duplication, it avoids it in the test vector setup which is were it would hurt the most. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29747#issuecomment-3929116938
Please review this PR which brings `jdk.nio.zipfs.ZipFileSystem` `END` header validation into behavioral alignment with the corresponding checks in `java.util.zip.ZipFile`.
This brings two validation checks over to `ZipFileSystem`:
* Rejection of END headers with a CEN size larger than `ArraysSupport.SOFT_MAX_ARRAY_LENGTH` (JDK-8272746) * Rejection of END headers with a total entry count which cannot fit within the CEN byte array (JDK-8341625)
The test `test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java` is updated to to verify that ZIP files rejected by the `ZipFile` constructor are now also rejected by `ZipFileSystem.newFileSystem`.
Tangentially, `ZipFileSystem.findEND` is updated to make `END.centot` a `long` instead of an `int`. This avoids a narrowing conversion which otherwise prevents validating a larger than Integer.MAX_VALUE number of CEN entries. Similar adjustments to `ZipFile` was done in JDK-8341625.
`ZipFile.Source.initCEN` is updated with some minor code style / code comment changes to make side-by-side diffs less noisy. Additionally, validated `end.cenlen` and `end.centot` values are now consistently converted to `int` using `Math.toIntExact`.
Eirik Bjørsnøs has updated the pull request incrementally with three additional commits since the last revision: - Replace ZipFile reference in clas comment with ZipFileSystem - Remove spurious '*' - Extract test vector setup into ZipUtils class reusable across ZipFile/ZipFileSystem tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29747/files - new: https://git.openjdk.org/jdk/pull/29747/files/17b8a72c..d6fc0aee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29747&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29747&range=00-01 Stats: 656 lines in 3 files changed: 417 ins; 221 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/29747.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29747/head:pull/29747 PR: https://git.openjdk.org/jdk/pull/29747
On Thu, 19 Feb 2026 18:44:32 GMT, Eirik Bjørsnøs <eirbjo@openjdk.org> wrote:
Please review this PR which brings `jdk.nio.zipfs.ZipFileSystem` `END` header validation into behavioral alignment with the corresponding checks in `java.util.zip.ZipFile`.
This brings two validation checks over to `ZipFileSystem`:
* Rejection of END headers with a CEN size larger than `ArraysSupport.SOFT_MAX_ARRAY_LENGTH` (JDK-8272746) * Rejection of END headers with a total entry count which cannot fit within the CEN byte array (JDK-8341625)
Test vector setup in `test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java` is extracted to a new test lib utility class `jdk.test.lib.util.ZipUtils`. `EndOfCenValidation` is then copied to `test/jdk/jdk/nio/zipfs` and adjusted to test `ZipFileSystem` instead of `ZipFile`.
Tangentially, `ZipFileSystem.findEND` is updated to make `END.centot` a `long` instead of an `int`. This avoids a narrowing conversion which otherwise prevents validating a larger than Integer.MAX_VALUE number of CEN entries. Similar adjustments to `ZipFile` was done in JDK-8341625.
`ZipFile.Source.initCEN` is updated with some minor code style / code comment changes to make side-by-side diffs less noisy. Additionally, validated `end.cenlen` and `end.centot` values are now consistently converted to `int` using `Math.toIntExact`.
Eirik Bjørsnøs has updated the pull request incrementally with three additional commits since the last revision:
- Replace ZipFile reference in clas comment with ZipFileSystem - Remove spurious '*' - Extract test vector setup into ZipUtils class reusable across ZipFile/ZipFileSystem tests
thank you for the update Eirik. Overall looks good. You might get some asks to remove the extra blank lines here and there. I have no strong preference. I think the copyright should just be 2026 for these new files but need to confirm test/jdk/jdk/nio/zipfs/EndOfCenValidation.java line 2:
1: /* 2: * Copyright (c) 2023, 2026, Oracle and/or its affiliates. All rights reserved.
As this is a new file, I believe this should be 2026 only test/lib/jdk/test/lib/util/ZipUtils.java line 2:
1: /* 2: * Copyright (c) 2023, 2026, Oracle and/or its affiliates. All rights reserved.
Same comment on copyright only being 2026 ------------- PR Review: https://git.openjdk.org/jdk/pull/29747#pullrequestreview-3833307379 PR Review Comment: https://git.openjdk.org/jdk/pull/29747#discussion_r2834291100 PR Review Comment: https://git.openjdk.org/jdk/pull/29747#discussion_r2834293304
On Fri, 20 Feb 2026 17:30:59 GMT, Lance Andersen <lancea@openjdk.org> wrote:
Overall looks good. You might get some asks to remove the extra blank lines here and there. I have no strong preference.
Comparing with mainline I don't see I added much blank lines. If there is any particular places you'd like me to trim existing ones, let me know.
I think the copyright should just be 2026 for these new files but need to confirm
My reasoning here is that while these are new files, they are copies containing intellectual property written in the period 2023-2026. I am by no means a lawyer, but shouldn't these copyright headers reflect the IP contained in the file, not the file history itsef? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29747#issuecomment-3936269239
On Thu, 19 Feb 2026 18:44:32 GMT, Eirik Bjørsnøs <eirbjo@openjdk.org> wrote:
Please review this PR which brings `jdk.nio.zipfs.ZipFileSystem` `END` header validation into behavioral alignment with the corresponding checks in `java.util.zip.ZipFile`.
This brings two validation checks over to `ZipFileSystem`:
* Rejection of END headers with a CEN size larger than `ArraysSupport.SOFT_MAX_ARRAY_LENGTH` (JDK-8272746) * Rejection of END headers with a total entry count which cannot fit within the CEN byte array (JDK-8341625)
Test vector setup in `test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java` is extracted to a new test lib utility class `jdk.test.lib.util.ZipUtils`. `EndOfCenValidation` is then copied to `test/jdk/jdk/nio/zipfs` and adjusted to test `ZipFileSystem` instead of `ZipFile`.
Tangentially, `ZipFileSystem.findEND` is updated to make `END.centot` a `long` instead of an `int`. This avoids a narrowing conversion which otherwise prevents validating a larger than Integer.MAX_VALUE number of CEN entries. Similar adjustments to `ZipFile` was done in JDK-8341625.
`ZipFile.Source.initCEN` is updated with some minor code style / code comment changes to make side-by-side diffs less noisy. Additionally, validated `end.cenlen` and `end.centot` values are now consistently converted to `int` using `Math.toIntExact`.
Eirik Bjørsnøs has updated the pull request incrementally with three additional commits since the last revision:
- Replace ZipFile reference in clas comment with ZipFileSystem - Remove spurious '*' - Extract test vector setup into ZipUtils class reusable across ZipFile/ZipFileSystem tests
test/jdk/jdk/nio/zipfs/EndOfCenValidation.java line 31:
29: * @run junit/othervm EndOfCenValidation 30: */ 31:
Here is an example of a blank line some might ask to have removed test/jdk/jdk/nio/zipfs/EndOfCenValidation.java line 88:
86: public void shouldRejectTooLargeCenSize() throws IOException { 87: int size = MAX_CEN_SIZE + 1; 88:
Another blank line example. Again, I don't have a strong preference, but I have been asked in some PRs to consider it. I wouldn't rush to do anything, my comment was more of an fyi ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29747#discussion_r2834464258 PR Review Comment: https://git.openjdk.org/jdk/pull/29747#discussion_r2834469721
On Fri, 20 Feb 2026 18:05:36 GMT, Lance Andersen <lancea@openjdk.org> wrote:
Eirik Bjørsnøs has updated the pull request incrementally with three additional commits since the last revision:
- Replace ZipFile reference in clas comment with ZipFileSystem - Remove spurious '*' - Extract test vector setup into ZipUtils class reusable across ZipFile/ZipFileSystem tests
test/jdk/jdk/nio/zipfs/EndOfCenValidation.java line 88:
86: public void shouldRejectTooLargeCenSize() throws IOException { 87: int size = MAX_CEN_SIZE + 1; 88:
Another blank line example.
Again, I don't have a strong preference, but I have been asked in some PRs to consider it.
I wouldn't rush to do anything, my comment was more of an fyi
Thanks Lance, I pushed a commit which reduces some of the excessive vertical space. I kept the line following the jtreg comment section since this seems to be very common and I prefer some separation before the import section. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29747#discussion_r2834538507
Please review this PR which brings `jdk.nio.zipfs.ZipFileSystem` `END` header validation into behavioral alignment with the corresponding checks in `java.util.zip.ZipFile`.
This brings two validation checks over to `ZipFileSystem`:
* Rejection of END headers with a CEN size larger than `ArraysSupport.SOFT_MAX_ARRAY_LENGTH` (JDK-8272746) * Rejection of END headers with a total entry count which cannot fit within the CEN byte array (JDK-8341625)
Test vector setup in `test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java` is extracted to a new test lib utility class `jdk.test.lib.util.ZipUtils`. `EndOfCenValidation` is then copied to `test/jdk/jdk/nio/zipfs` and adjusted to test `ZipFileSystem` instead of `ZipFile`.
Tangentially, `ZipFileSystem.findEND` is updated to make `END.centot` a `long` instead of an `int`. This avoids a narrowing conversion which otherwise prevents validating a larger than Integer.MAX_VALUE number of CEN entries. Similar adjustments to `ZipFile` was done in JDK-8341625.
`ZipFile.Source.initCEN` is updated with some minor code style / code comment changes to make side-by-side diffs less noisy. Additionally, validated `end.cenlen` and `end.centot` values are now consistently converted to `int` using `Math.toIntExact`.
Eirik Bjørsnøs has updated the pull request incrementally with one additional commit since the last revision: Dial down on blank lines as vertical space ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29747/files - new: https://git.openjdk.org/jdk/pull/29747/files/d6fc0aee..89cb85f5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29747&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29747&range=01-02 Stats: 26 lines in 3 files changed: 0 ins; 26 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29747.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29747/head:pull/29747 PR: https://git.openjdk.org/jdk/pull/29747
On Fri, 20 Feb 2026 18:28:54 GMT, Eirik Bjørsnøs <eirbjo@openjdk.org> wrote:
Please review this PR which brings `jdk.nio.zipfs.ZipFileSystem` `END` header validation into behavioral alignment with the corresponding checks in `java.util.zip.ZipFile`.
This brings two validation checks over to `ZipFileSystem`:
* Rejection of END headers with a CEN size larger than `ArraysSupport.SOFT_MAX_ARRAY_LENGTH` (JDK-8272746) * Rejection of END headers with a total entry count which cannot fit within the CEN byte array (JDK-8341625)
Test vector setup in `test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java` is extracted to a new test lib utility class `jdk.test.lib.util.ZipUtils`. `EndOfCenValidation` is then copied to `test/jdk/jdk/nio/zipfs` and adjusted to test `ZipFileSystem` instead of `ZipFile`.
Tangentially, `ZipFileSystem.findEND` is updated to make `END.centot` a `long` instead of an `int`. This avoids a narrowing conversion which otherwise prevents validating a larger than Integer.MAX_VALUE number of CEN entries. Similar adjustments to `ZipFile` was done in JDK-8341625.
`ZipFile.Source.initCEN` is updated with some minor code style / code comment changes to make side-by-side diffs less noisy. Additionally, validated `end.cenlen` and `end.centot` values are now consistently converted to `int` using `Math.toIntExact`.
Eirik Bjørsnøs has updated the pull request incrementally with one additional commit since the last revision:
Dial down on blank lines as vertical space
Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29747#pullrequestreview-3869202563
On Fri, 20 Feb 2026 18:28:54 GMT, Eirik Bjørsnøs <eirbjo@openjdk.org> wrote:
Please review this PR which brings `jdk.nio.zipfs.ZipFileSystem` `END` header validation into behavioral alignment with the corresponding checks in `java.util.zip.ZipFile`.
This brings two validation checks over to `ZipFileSystem`:
* Rejection of END headers with a CEN size larger than `ArraysSupport.SOFT_MAX_ARRAY_LENGTH` (JDK-8272746) * Rejection of END headers with a total entry count which cannot fit within the CEN byte array (JDK-8341625)
Test vector setup in `test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java` is extracted to a new test lib utility class `jdk.test.lib.util.ZipUtils`. `EndOfCenValidation` is then copied to `test/jdk/jdk/nio/zipfs` and adjusted to test `ZipFileSystem` instead of `ZipFile`.
Tangentially, `ZipFileSystem.findEND` is updated to make `END.centot` a `long` instead of an `int`. This avoids a narrowing conversion which otherwise prevents validating a larger than Integer.MAX_VALUE number of CEN entries. Similar adjustments to `ZipFile` was done in JDK-8341625.
`ZipFile.Source.initCEN` is updated with some minor code style / code comment changes to make side-by-side diffs less noisy. Additionally, validated `end.cenlen` and `end.centot` values are now consistently converted to `int` using `Math.toIntExact`.
Eirik Bjørsnøs has updated the pull request incrementally with one additional commit since the last revision:
Dial down on blank lines as vertical space
Thanks you Lance! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29747#issuecomment-3976443848
On Mon, 16 Feb 2026 15:15:28 GMT, Eirik Bjørsnøs <eirbjo@openjdk.org> wrote:
Please review this PR which brings `jdk.nio.zipfs.ZipFileSystem` `END` header validation into behavioral alignment with the corresponding checks in `java.util.zip.ZipFile`.
This brings two validation checks over to `ZipFileSystem`:
* Rejection of END headers with a CEN size larger than `ArraysSupport.SOFT_MAX_ARRAY_LENGTH` (JDK-8272746) * Rejection of END headers with a total entry count which cannot fit within the CEN byte array (JDK-8341625)
Test vector setup in `test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java` is extracted to a new test lib utility class `jdk.test.lib.util.ZipUtils`. `EndOfCenValidation` is then copied to `test/jdk/jdk/nio/zipfs` and adjusted to test `ZipFileSystem` instead of `ZipFile`.
Tangentially, `ZipFileSystem.findEND` is updated to make `END.centot` a `long` instead of an `int`. This avoids a narrowing conversion which otherwise prevents validating a larger than Integer.MAX_VALUE number of CEN entries. Similar adjustments to `ZipFile` was done in JDK-8341625.
`ZipFile.Source.initCEN` is updated with some minor code style / code comment changes to make side-by-side diffs less noisy. Additionally, validated `end.cenlen` and `end.centot` values are now consistently converted to `int` using `Math.toIntExact`.
This pull request has now been integrated. Changeset: d62b9f78 Author: Eirik Bjørsnøs <eirbjo@openjdk.org> URL: https://git.openjdk.org/jdk/commit/d62b9f78ca4a35bb6c5f665172c7abce4dac56ca Stats: 692 lines in 5 files changed: 425 ins; 229 del; 38 mod 8377992: (zipfs) Align ZipFileSystem END header validation with the ZipFile implementation Reviewed-by: lancea ------------- PR: https://git.openjdk.org/jdk/pull/29747
participants (2)
-
Eirik Bjørsnøs
-
Lance Andersen