JDK-8314450 : ZipFile rejects ZIP file that some zip tools can parse without errors
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.jar
  • Affected Version: 20.0.2
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2023-08-16
  • Updated: 2024-11-18
  • Resolved: 2024-11-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdFixed
Related Reports
Relates :  
JDK-8313765 - Invalid CEN header (invalid zip64 extra data field size)
Description
The attached TEST.zip file is accepted by the latest JDK8u382, by the JDK20GA, by the zip, by the Windows Explorer and macOS Archive Utility.
That zip file also passed the integrity test via "zip -T".

But it is rejected by the latest update of JDK 20.0.2, actually by all JDK11+.

See discussion here: https://github.com/openjdk/jdk/pull/15273

Suggestion to use the "-Djdk.util.zip.disableZip64ExtraFieldValidation=true" does not work well here. Using that property will completely disable more important checks.
Validation of the negative values is much more important which was a root cause of the related bug.
Comments
See APPNOTE.TXT 4.5.3 -Zip64 Extended Information Extra Field (0x0001): The following is the layout of the zip64 extended information "extra" block. If one of the size or offset fields in the Local or Central directory record is too small to hold the required data, a Zip64 extended information record is created. The order of the fields in the zip64 extended information record is fixed, but the fields MUST only appear if the corresponding Local or Central directory record field is set to 0xFFFF or 0xFFFFFFFF. The attached ZIP file has a Zip64 Extended Information Extra Field with a data block size of 2. No field in the CEN is has the 4 or 2-byte MAGIC values. Since the specification clearly states that "the fields MUST only appear if the corresponding Local or Central directory record field is set to 0xFFFF or 0xFFFFFFFF.", this CEN should not have a Zip64 extra field. In any case, a two-byte Zip64 data size is not valid for any specified component of the Zip64 extra data field. The attached ZIP violates the APPNOTE.TXT specification. Closing this issue.
18-11-2024