[
https://issues.apache.org/jira/browse/COMPRESS-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16494922#comment-16494922
]
Stefan Bodewig commented on COMPRESS-454:
-----------------------------------------
[~mikegike] can you try the change I suggest above?
Unfortunately there are ZIP implementations out there that don't use a
signature for the DD. The PKWare spec didn't define a signature and the InfoZIP
folks invented one. So the code needs to deal with DDs that either contain a
signature or not. It assumes it has found a DD without signature if a LFH or
CFH has been hit.
> Bug in determination of Signature for STORED ZipArchive with data descriptor
> ----------------------------------------------------------------------------
>
> Key: COMPRESS-454
> URL: https://issues.apache.org/jira/browse/COMPRESS-454
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
> Affects Versions: 1.16.1
> Environment: Windows, JDK 9.0.4
> Reporter: Mike Scholl
> Priority: Major
>
> The archive file contains a data descriptor, which is not recognized and lead
> to "
> {code:java}
> java.util.zip.ZipException: Unexpected record signature: 0X302D3831{code}
>
>
> The process to check if one block contains a signature(ZipArchiveInputStream
> -> bufferContainsSignature) seems to be a little buggy.
> The following block is processed when the exception comes up, for the file.
> [13, 10, 60, 73, 66, 65, 78, 62, 65, 84, 52, 48, 54, 48, 48, 48, 48, 48, 48,
> 48, 48, 55, 53, 48, 48, 48, 53, 51, 60, 47, 73, 66, 65, 78, 62, 13, 10, 60,
> 47, 73, 100, 62, 13, 10, 60, 47, 67, 100, 116, 114, 65, 99, 99, 116, 62, 13,
> 10, 60, 47, 82, 108, 116, 100, 80, 116, 105, 101, 115, 62, 13, 10, 60, 82,
> 108, 116, 100, 65, 103, 116, 115, 62, 13, 10, 60, 68, 98, 116, 114, 65, 103,
> 116, 62, 13, 10, 60, 70, 105, 110, 73, 110, 115, 116, 110, 73, 100, 62, 13,
> 10, 60, 66, 73, 67, 62, 66, 65, 87, 65, 65, 84, 87, 87, 88, 88, 88, 60, 47,
> 66, 73, 67, 62, 13, 10, 60, 47, 70, 105, 110, 73, 110, 115, 116, 110, 73,
> 100, 62, 13, 10, 60, 47, 68, 98, 116, 114, 65, 103, 116, 62, 13, 10, 60, 67,
> 100, 116, 114, 65, 103, 116, 62, 13, 10, 60, 70, 105, 110, 73, 110, 115, 116,
> 110, 73, 100, 62, 13, 10, 60, 66, 73, 67, 62, 66, 65, 87, 65, 65, 84, 87, 87,
> 88, 88, 88, 60, 47, 66, 73, 67, 62, 13, 10, 60, 47, 70, 105, 110, 73, 110,
> 115, 116, 110, 73, 100, 62, 13, 10, 60, 47, 67, 100, 116, 114, 65, 103, 116,
> 62, 13, 10, 60, 47, 82, 108, 116, 100, 65, 103, 116, 115, 62, 13, 10, 60, 80,
> 117, 114, 112, 62, 13, 10, 60, 67, 100, 62, 79, 84, 72, 82, 60, 47, 67, 100,
> 62, 13, 10, 60, 47, 80, 117, 114, 112, 62, 13, 10, 60, 82, 109, 116, 73, 110,
> 102, 62, 13, 10, 60, 83, 116, 114, 100, 62, 13, 10, 60, 67, 100, 116, 114,
> 82, 101, 102, 73, 110, 102, 62, 13, 10, 60, 84, 112, 62, 13, 10, 60, 67, 100,
> 79, 114, 80, 114, 116, 114, 121, 62, 13, 10, 60, 67, 100, 62, 83, 67, 79, 82,
> 60, 47, 67, 100, 62, 13, 10, 60, 47, 67, 100, 79, 114, 80, 114, 116, 114,
> 121, 62, 13, 10, 60, 47, 84, 112, 62, 13, 10, 60, 82, 101, 102, 62, 53, 48,
> 49, 48, 54, 52, 55, 52, 49, 52, 60, 47, 82, 101, 102, 62, 13, 10, 60, 47, 67,
> 100, 116, 114, 82, 101, 102, 73, 110, 102, 62, 13, 10, 60, 47, 83, 116, 114,
> 100, 62, 13, 10, 60, 47, 82, 109, 116, 73, 110, 102, 62, 13, 10, 60, 47, 84,
> 120, 68, 116, 108, 115, 62, 13, 10, 60, 47, 78, 116, 114, 121, 68, 116, 108,
> 115, 62, 13, 10, 60, 47, 78, 116, 114, 121, 62, 13, 10, 60, 47, 83, 116, 109,
> 116, 62, 13, 10, 60, 47, 66, 107, 84, 111, 67, 115, 116, 109, 114, 83, 116,
> 109, 116, 62, 13, 10, 60, 47, 68, 111, 99, 117, 109, 101, 110, 116, 62, 80,
> 75, 7, 8, -70, -19, -86, -114, -92, 11, 0, 0, -92, 11, 0, 0]
> The lastRead variable is set to 497. The offset is 15.
> The *for* in *bufferContainsSignature* do not recognize the data descriptor
> because it goes only to the *lastRead - 4*.
> In the following method *cacheBytesRead* only 15 bytes from 497 to 512 are
> cached, so the P((byte)80) on position 496 is not cached in the next block.
> My suggestion for the solution is to check all bytes(*buf.array().length -
> 4*) in ZipArchiveInputStream -> bufferContainsSignature, if they contain the
> ZipArchiveInputStream.LFH, ZipArchiveInputStream.CFH or
> ZipArchiveInputStream.DD bytes, but maybe I miss something.
> However, seems to work for the example files.
> Sorry not to share the example files they are created by a customer.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
