Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Re: --max-filesize and --compressed
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Andreas Mohr via curl-users <curl-users_at_lists.haxx.se>
Date: Mon, 2 Mar 2026 12:09:32 +0100
Hi,
On Mon, Mar 02, 2026 at 11:13:32AM +0100, Daniel Stenberg via curl-users wrote:
> On Mon, 2 Mar 2026, Stefan Eissing wrote:
>
> > My personal preference would be to apply this to the uncompressed size
> > as well.
>
> I'm leaning towards that as well, and it might be as simple as this:
>
> https://github.com/curl/curl/pull/20787
Another important thing might be the question of
defaults (default behaviour).
Since a decompression bomb is about
achieving near-infinite file size from tiny origin data
(and with raw CPU-generated bandwidth!),
its robust prevention seems to be
much more pressing than
experiencing eventual overflow during
"normal" download activity.
Thus, perhaps a limit value *) for compression-based activity should be
instated *by default* (else
in many cases this configuration state simply
*will not* have been customized, which translates into
any decompression bomb activity succeeding).
But that would probably mean that
decoupling this compression-related config state from
--max-filesize state is
quite important (since/if it has
sufficiently different/unrelated qualities).
*) a suitable one - and perhaps a relatively low value (10GB? Or even much
less, to actively encourage people to have their own suitably larger limit value
configured?) - and perhaps choose a special "marker" limit value, to let
people easily determine (research) that they managed to hit that special
limit value
Anyway, some food for thought.
Greetings
Andreas Mohr
Date: Mon, 2 Mar 2026 12:09:32 +0100
Hi,
On Mon, Mar 02, 2026 at 11:13:32AM +0100, Daniel Stenberg via curl-users wrote:
> On Mon, 2 Mar 2026, Stefan Eissing wrote:
>
> > My personal preference would be to apply this to the uncompressed size
> > as well.
>
> I'm leaning towards that as well, and it might be as simple as this:
>
> https://github.com/curl/curl/pull/20787
Another important thing might be the question of
defaults (default behaviour).
Since a decompression bomb is about
achieving near-infinite file size from tiny origin data
(and with raw CPU-generated bandwidth!),
its robust prevention seems to be
much more pressing than
experiencing eventual overflow during
"normal" download activity.
Thus, perhaps a limit value *) for compression-based activity should be
instated *by default* (else
in many cases this configuration state simply
*will not* have been customized, which translates into
any decompression bomb activity succeeding).
But that would probably mean that
decoupling this compression-related config state from
--max-filesize state is
quite important (since/if it has
sufficiently different/unrelated qualities).
*) a suitable one - and perhaps a relatively low value (10GB? Or even much
less, to actively encourage people to have their own suitably larger limit value
configured?) - and perhaps choose a special "marker" limit value, to let
people easily determine (research) that they managed to hit that special
limit value
Anyway, some food for thought.
Greetings
Andreas Mohr
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2026-03-02