Details
-
Enhancement
-
Resolution: Fixed
-
P4
-
21
-
None
-
b10
-
generic
-
generic
Description
ZipInputStream.readEnd currently expects 8-byte size and csize fields in the data descriptor header if and only if the actually numbers of compressed or uncompressed bytes exceeds the Zip64 limit of 0XFFFFFFFF.
This prevents parsing of small zip64 entries, such as the ones created using:
echo hello | zip -fd > hello.zip
The APPNOTE.txt specification indicates that such files are valid, so ZipInputStream should be able to parse them:
When extracting, if the zip64 extended information extra
field is present for the file the compressed and
uncompressed sizes will be 8 byte values.
The solution is to update ZipOutputStream.readEnd to check for the presence of Zip64 extra information fields in the LOC.
This prevents parsing of small zip64 entries, such as the ones created using:
echo hello | zip -fd > hello.zip
The APPNOTE.txt specification indicates that such files are valid, so ZipInputStream should be able to parse them:
When extracting, if the zip64 extended information extra
field is present for the file the compressed and
uncompressed sizes will be 8 byte values.
The solution is to update ZipOutputStream.readEnd to check for the presence of Zip64 extra information fields in the LOC.
Attachments
Issue Links
- csr for
-
JDK-8323583 Allow ZipInputStream.readEnd to parse small Zip64 ZIP files
- Closed
- is blocked by
-
JDK-8314891 Additional Zip64 extra header validation
- Resolved
- relates to
-
JDK-8298530 ZipInputStream.readEnd fails for certain ZIP64 archives with small files
- Open
-
JDK-7073588 ZipInput/OutputStream handling of the data descriptor is wrong for big entries
- Closed
(1 links to)