[
https://issues.apache.org/jira/browse/COMPRESS-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16405994#comment-16405994
]
Stefan Bodewig commented on COMPRESS-445:
-----------------------------------------
Client code could always wrap the stream returned by {{ZipFile}} into something
like the POI's {{ThresholdInputStream}} - or check the entry's uncompressed
size before even starting the decompression. It doesn't feel right to me to
bake that into {{ZipFile}} in particular as {{ZipArchiveInputStream}} and
{{SevenZFile}} would need the same treatment as well (possibly even more than
those, likely most of the compressor streams as well).
To me it looks as if this would better be solved in a layer on top of our
abstractions.
> Zip Bomb Detection
> ------------------
>
> Key: COMPRESS-445
> URL: https://issues.apache.org/jira/browse/COMPRESS-445
> Project: Commons Compress
> Issue Type: Improvement
> Components: Archivers
> Reporter: PJ Fanning
> Priority: Major
>
> It would be a nice feature if ZipFile had support for detecting Zip Bombs.
> Apache Poi has an implementation based on the java util ZipFile but this
> relies on Reflection and changes in Java 10 mean this code will not work in
> that version.
> [https://github.com/apache/poi/blob/trunk/src/ooxml/java/org/apache/poi/openxml4j/util/ZipSecureFile.java]
> One option would be to add equivalent change support in commons-compress and
> for Poi to use the commons version.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
