[
https://issues.apache.org/jira/browse/ODFTOOLKIT-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14650643#comment-14650643
]
Damjan Jovanovic commented on ODFTOOLKIT-402:
---------------------------------------------
On https://commons.apache.org/proper/commons-compress/zip.html commons-compress
explains the following:
{quote}
ZIP archives know a feature called the data descriptor which is a way to store
an entry's length after the entry's data. This can only work reliably if the
size information can be taken from the central directory or the data itself can
signal it is complete, which is true for data that is compressed using the
DEFLATED compression algorithm.
ZipFile has access to the central directory and can extract entries using the
data descriptor reliably. The same is true for ZipArchiveInputStream as long as
the entry is DEFLATED. For STORED entries ZipArchiveInputStream can try to read
ahead until it finds the next entry, but this approach is not safe and has to
be enabled by a constructor argument explicitly.
If possible, you should always prefer ZipFile over ZipArchiveInputStream.
{quote}
Indeed, I can read all the entries with ZipFile instead of ZipInputStream:
{quote}
ZipFile zipFile = new ZipFile(new File(args[0]));
Enumeration<? extends ZipEntry> entries = zipFile.entries();
while (entries.hasMoreElements()) {
ZipEntry zipEntry = entries.nextElement();
System.out.println(zipEntry.getName());
}
{quote}
ZipHelper's constructor that uses a ZipFile instead of a byte[] is never
called. Maybe it should be? Or maybe odftoolkit should be using
commons-compress instead of java.util.zip for more robust parsing?
> ZipException on encrypted files: only DEFLATED entries can have EXT descriptor
> ------------------------------------------------------------------------------
>
> Key: ODFTOOLKIT-402
> URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-402
> Project: ODF Toolkit
> Issue Type: Bug
> Components: odfdom
> Reporter: Damjan Jovanovic
>
> Any encrypted ODF file written by LibreOffice reproducibly fails to open:
> Document document = Document.loadDocument(new File(args[0]), "abc");
> due to an exception produced early in parsing the ZIP file. The exception is
> masked by the NullPointerException in the exception handler as per
> ODFTOOLKIT-401, but if that is patched, the original exception is this:
> java.util.zip.ZipException: only DEFLATED entries can have EXT descriptor
> at java.util.zip.ZipInputStream.readLOC(ZipInputStream.java:309)
> at java.util.zip.ZipInputStream.getNextEntry(ZipInputStream.java:121)
> at ReadZip.entriesToMap(ReadZip.java:64)
> at org.odftoolkit.odfdom.pkg.ZipHelper.entriesToMap(ZipHelper.java:87)
> at org.odftoolkit.odfdom.pkg.OdfPackage.readZip(OdfPackage.java:443)
> at
> org.odftoolkit.odfdom.pkg.OdfPackage.initializeZip(OdfPackage.java:422)
> at org.odftoolkit.odfdom.pkg.OdfPackage.<init>(OdfPackage.java:250)
> at org.odftoolkit.odfdom.pkg.OdfPackage.loadPackage(OdfPackage.java:405)
> at org.odftoolkit.simple.Document.loadDocument(Document.java:351)
> at local.Main.main(Main.java:21)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
