> Am 02.03.2026 um 12:38 schrieb Andreas Mohr via curl-users
> <[email protected]>:
>
> On Mon, Mar 02, 2026 at 09:53:34AM +0100, Daniel Stenberg via curl-users
> wrote:
>> Would it make sense to have some kind of limit to the "explosion factor" ?
>
> Ah, indeed, possibly.
> An "explosion factor" config state seems to be
> much more precision-related *) than
> a raw result file size config state.
> (since the actually hurting most relevant characteristic
> of a compression bomb is
> the *very abnormally* high explosion factor vs.
> its tiny origin data, and especially vs.
> plain "normal" decompression examples).
>
> *)
> - quite reliably catches compression bombs
> - is more future-proof than
> enacting some raw fixed file size limit (vs.
> eternally growing capabilities of systems!)
>
>
> OTOH with an input file of
> say 1GB and explosion factor limit of
> only 100 **), one would still end up with
> a dangerously large 100GB file size...
>
> **) which might be already too low for
> many legitimate decompression activities
>
> So, do instead resort to
> a plain file-size-based limit after all?
Do not forget the various use cases where the output is piped somewhere or
immediately consumed by a libcurl application. If one pipes a WebSocket
connection to some event processing, a limit might do more harm than good.
Regards,
Stefan
>
> Greetings
>
> Andreas Mohr
> --
> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users
> Etiquette: https://curl.se/mail/etiquette.html
--
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users
Etiquette: https://curl.se/mail/etiquette.html
