On #curl's --max-filesize and --compressed. Should we do something about the "compression bomb" risk?
On #curl's --max-filesize and --compressed. Should we do something about the "compression bomb" risk?
@bagder It would not contradict the documentation if it applied after decompression.
The crux is backwards compat, but maybe that would be acceptable breakage?
@bagder Qt has a decompression ratio check that kicks in after 10MiB by default, maybe something like that would be good enough?
(though this usually catches valid, highly compressable data; e.g. repetitive log files)
https://doc.qt.io/qt-6/qnetworkrequest.html#setDecompressedSafetyCheckThreshold
--max-filesize applies on the size of the file that curl produces. not just the transfer size.@bagder I do like “the --max-filesize limit be applied on the uncompressed size as
well” but I don't know how you would implement it. How will you know in advance what the uncompressed size is going to be?
Therefore, I believe the current behavior is sufficient and portable. More importantly, it is not a surprise.
--max-filesize should probably have been called --max-transfersize, if that is what it does
--max-transfersize for the on-wire bytes
--max-filesize for the locally stored bytes
But that would be a breaking change changing the semantics of --max-filesize.
Maybe deprecate it and add --max-transfer-size and --max-file-size (note the extra "-").