[
https://issues.apache.org/jira/browse/TIKA-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730185#action_12730185
]
Chris A. Mattmann commented on TIKA-216:
----------------------------------------
Hey Jukka, Tika'ers:
Do you see this as a blocker to 0.4? I'd like to cut an RC in the next day or
so, but this is still open and I wanted to check with you and get your thoughts?
My vote is -1 for this being a blocker -- I think we can fix it in 0.5. Please
let me know ASAP -- if I don't hear back in the next 48 hours I'm going to go
ahead and push this to 0.5. If I do hear back and there is significant support
that this can go to 0.5, then I will do so earlier and move on to the RC.
Cheers,
Chris
> Zip bomb prevention
> -------------------
>
> Key: TIKA-216
> URL: https://issues.apache.org/jira/browse/TIKA-216
> Project: Tika
> Issue Type: New Feature
> Components: parser
> Reporter: Jukka Zitting
> Assignee: Jukka Zitting
> Fix For: 0.4
>
>
> It would be good to have a mechanism that automatically detects a "zip bomb",
> i.e. a compressed document that expands to excessive amounts of extracted
> text. The classic example is the 42.zip file that's just 42kB in size, but
> expands to about 4 *petabytes* when all layers are fully uncompressed.
> A simple preventive measure could be a Parser decorator that counts the
> number of input bytes and the output characters, and fails with a
> TikaException when the ratio exceeds some configurable limit.
> As another preventive measure, the decorator could also keep track of the
> time (and perhaps even memory, if possible) it takes to process the input
> document. A TikaException would be thrown if processing time exceeds some
> configurable limit.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
