The main purpose of the zip bomb detection is to safely handle untrusted input.
Since a workbook that has already been fully read into memory has passed the
safety test, I suppose you could consider it quasi-safe with regard to writing
it back out.
If you can't think of a way that a latent zip bomb could unwrap itself while
writing the workbook that wasn't a result of poor (trusted) code, then I would
agree with removing this limit when writing.
Not being a security expert, the safer option is to set different read and
write limits.
Let's continue the discussion on the POI dev [email protected]
<mailto:[email protected]>.
As I wrote in a comment to that bug, I had the same issue today. I looked at
the code, and what happens is that data is written to a temporary file. When
SXSSFWorkbook.write() is called, the header is written, and then the data
from the temporary file is read back in and appended.
This is done in the private method SXSSFWorkbook.injectData().
If we can trust that the temporary data has not been tampered with (and in
which case there'd be a much worse problem), I think we can drop the
heuristic for zip bomb detection when reading the data back in.
If we just replace the first line in injectData():
ZipFile zip = ZipHelper.openZipFile(zipfile);
by
ZipFile zip = new ZipFile(zipfile);
that should do it.
(ZipHelper also checks that zipfile exists, but if it doesn't that leads to
NPE afterwards eich IMHO is not better than IOException in that case.)
I could create a patch for this, but I'd like to discuss this first.
So what are the other devs opinions about this?
PS: Since this bug is marked RESOLVED FIXED, how should I submit a
patch? Reopen the bug and attach the patch or just mail the patch
to this list?
