Michael Mole created COMPRESS-364:
-------------------------------------
Summary: ZipArchiveInputStream.closeEntry does not properly
advance to next entry if there are junk bytes at end of data section
Key: COMPRESS-364
URL: https://issues.apache.org/jira/browse/COMPRESS-364
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Affects Versions: 1.12
Reporter: Michael Mole
Priority: Minor
ZipArchiveInputStream.closeEntry() will not properly advance to the next entry
causing the next call to getNextZipEntry to incorrectly return null if there
are junk bytes at the end of the compressed data section.
More specifically, I found a case where the first entry's local header says
that its compressed data size is 620 bytes. There are in fact 620 bytes before
the next local header. However, when the compressed data is inflated, it only
requires 618 of the 620 bytes to fully inflate (i.e. before it encounters the
DEFLATE end of data code). This means that there is complete DEFLATE compressed
data + extra garbage bytes after it, all within the specified zip entry data
section.
The commons compress ZipArchiveInputStream streaming implementation doesn't
exactly read on zip entry boundaries, but instead it reads 512 bytes at a time.
As a result it tends to read more bytes than necessary per entry and then seek
back to the beginning of the next entry. When it seeks back, it assumes that
number of bytes that were required to be read to reach the end of the zip entry
is the same as the number of bytes needed to inflate the data. However that
assumption does not hold up in this case. 620 bytes need to be read to reach
then end of the zip entry, but only 618 were needed to inflate the data. After
the pushback, the closeEntry() method should perform a final drain of the
remaining bytes to reach the next local file header.
I've created a test case and fix. I will submit a pull request shortly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
