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.html
