You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Stefan Bodewig (JIRA)" <ji...@apache.org> on 2016/01/31 13:15:39 UTC

[jira] [Resolved] (COMPRESS-331) Some non TAR files are recognized by ArchiveStreamFactory

     [ https://issues.apache.org/jira/browse/COMPRESS-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Bodewig resolved COMPRESS-331.
-------------------------------------
       Resolution: Fixed
    Fix Version/s: 1.11

To me it really looks as if our checksum validation has been too lenient and I've made it more strict with git commit 1fb4298.

I've replaced the archive added as COMPRESS-117.tar with the first entry of the original archive appended to said bug report.

> Some non TAR files are recognized by ArchiveStreamFactory
> ---------------------------------------------------------
>
>                 Key: COMPRESS-331
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-331
>             Project: Commons Compress
>          Issue Type: Bug
>          Components: Archivers
>    Affects Versions: 1.10
>            Reporter: Jeremy Gustie
>             Fix For: 1.11
>
>         Attachments: ic_secure.png
>
>
> I ran into a case where a PNG file is being recognized as TAR because {{TarUtils.verifyCheckSum}} reports it as having a valid checksum (in this case the code thinks the stored checksum is 36936, unsigned is 31155 and signed is 19635). Because the stored checksum value is larger then the unsigned checksum it is treated as a valid TAR.
> I haven't spent enough time digging into the problem to see if there is a good alternative to the existing check that doesn't have false positives like this PNG file (which, if anyone is interested comes from an Android download).
> Also, I noticed a minor thing in the code: the comment in {{TarUtils.verifyCheckSum}} has the wrong bug number listed (it says 177 instead of 117).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)