commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Gregory (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COMPRESS-364) ZipArchiveInputStream.closeEntry does not properly advance to next entry if there are junk bytes at end of data section
Date Fri, 19 Aug 2016 16:09:22 GMT

    [ https://issues.apache.org/jira/browse/COMPRESS-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15428368#comment-15428368
] 

Gary Gregory commented on COMPRESS-364:
---------------------------------------

Hello Michael,

Can you provide a patch with a unit test?

Gary

> 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)

Mime
View raw message