[
https://issues.apache.org/jira/browse/COMPRESS-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-364.
-------------------------------------
Resolution: Fixed
Fix Version/s: 1.13
Thanks a lot, Mike, and sorry for the delay.
I've applied your patch, it will be part of the next release of compress.
> 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
> Fix For: 1.13
>
> Attachments:
> 0001-COMPRESS-364-ZipArchiveInputStream.closeEntry-fails-.patch
>
>
> 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)
