-
Enhancement
-
Resolution: Fixed
-
P4
-
21
-
None
-
b10
-
generic
-
generic
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.
- csr for
-
JDK-8323583 Allow ZipInputStream.readEnd to parse small Zip64 ZIP files
- Closed
- duplicates
-
JDK-8298530 ZipInputStream.readEnd fails for certain ZIP64 archives with small files
- Closed
- is blocked by
-
JDK-8314891 Additional Zip64 extra header validation
- Resolved
- relates to
-
JDK-7073588 ZipInput/OutputStream handling of the data descriptor is wrong for big entries
- Closed
-
JDK-8298530 ZipInputStream.readEnd fails for certain ZIP64 archives with small files
- Closed
(2 links to)