Stefan Bodewig wrote > This is using java.util.zip.ZipFile, not Commons Compress, right? I just > want to double check.
Correct Stefan Bodewig wrote > ... then the compressed and uncompressed sizes of each > ZipArchiveEntry are known before you try to read the stream. Can't you > simply reject reading entries who's uncompressed size is too big? Are those sizes taken from the central directory? Isn't it possible to tamper around those entries? if so, would you rely on those? Stefan Bodewig wrote > If you want to handle it on the stream level, there is a > BoundedInputStream class in Commons Compress that you could wrap around > the stream returned by ZipFile#getInputStream in order to enforce an > upper limit of bytes being read. To prevent false positives with people who put an insane amount of data into Excel sheets, I've chosen the ratio way, i.e. comparing how many bytes of the compressed stream are read vs. the uncompressed size. There's another limit check which does exactly what you've explained, but this defaults to around 2GB. Although POI has anyway a problem with the normal processing mode to deal with such big files, there's also a SAX streaming mode which can take benefit of this. I haven't dived into the compress code yet, but my hope is, that the ratio logic can be also applied there. For a reference I've looked through the archives to find related discussions [1], but maybe missed the private ones. So the discussion were similar to this thread, i.e. about taking the metadata/sizes from the central directory. So my approach would be to try to move to commons-compress, check if the ratio logic can be added and if this is possible, we might also need to look at the performance trade-off (if any?) and decide if we want a switchable implementation ... Andi [1] https://issues.apache.org/jira/browse/COMPRESS-445 https://issues.apache.org/jira/browse/COMPRESS-386 http://apache-commons.680414.n4.nabble.com/compress-Security-considerations-bomb-links-absolute-paths-tp4698822.html -- Sent from: http://apache-commons.680414.n4.nabble.com/Commons-User-f735979.html --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
