[
https://issues.apache.org/jira/browse/COMPRESS-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated COMPRESS-89:
----------------------------------
Attachment: ArchiveInputStream-canRead.patch
How about making this more general and moving the canRead method up to the
ArchiveInputStream base class? See the attached
ArchiveInputStream-canRead.patch for an example. This would allow Tika to avoid
casting the ArchiveInputStream instances it uses down to ZipArchiveInputStream,
and would potentially enable other archive formats to expose similar
information as we now do with zip.
> Better support for encrypted ZIP files
> --------------------------------------
>
> Key: COMPRESS-89
> URL: https://issues.apache.org/jira/browse/COMPRESS-89
> Project: Commons Compress
> Issue Type: Improvement
> Affects Versions: 1.0, 1.1
> Reporter: Antoni Mylka
> Assignee: Stefan Bodewig
> Fix For: 1.1
>
> Attachments: apache-maven-2.2.1-encrypted-passhello.zip,
> ArchiveInputStream-canRead.patch, commons-compress-encrypted.patch
>
>
> Currently when the ZipArchiveInputStream or ZipFile encounters an encrypted
> zip it bails out with cryptic exceptions like: 'invalid block type'. I would
> like to have two things:
> 1. an 'encrypted' flag in the ZipArchiveEntry class. It would be taken from
> the first bit of the 'general purpose flag'
> 2. more descriptive error messages, both in ZipFile and ZipArchiveInputStream
> It might be useful in case someone wants to implement proper support for
> encrypted zips, with methods to supply passwords/encryption keys and proper
> encryption/decryption algorithms.
> For the time being I just need to know if a file is encrypted or not.
> I will post a patch with a proposal of a solution in near future.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
