commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Bodewig (JIRA)" <>
Subject [jira] [Commented] (COMPRESS-331) Some non TAR files are recognized by ArchiveStreamFactory
Date Sun, 24 Jan 2016 12:09:39 GMT


Stefan Bodewig commented on COMPRESS-331:

Unfortunately there are tons of tar dialects that can all be extracted properly by GNU tar
- which usually means it would be a bug if Commons Compress failed to extract them. This means
we may need to refine our heuristics as we go.

I'm not convinced device numbers are good candidates, though, the fields may contain binary
data in the star case and there is no clear upper bound for them. I don't see any values that
are clear candidates for "garbage" in your case. I'll take another dive into GNU tar's code
base to see how they verify checksums.

> Some non TAR files are recognized by ArchiveStreamFactory
> ---------------------------------------------------------
>                 Key: COMPRESS-331
>                 URL:
>             Project: Commons Compress
>          Issue Type: Bug
>          Components: Archivers
>    Affects Versions: 1.10
>            Reporter: Jeremy Gustie
>         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

View raw message