Hello, On Tue, 8 Aug 2023, Jakub Jelinek via Gcc-patches wrote:
> What I'd really like to avoid is having all compiler bugs (primarily ICEs) > considered to be security bugs (e.g. DoS category), it would be terrible to > release every week a new compiler because of the "security" issues. > Running compiler on untrusted sources can trigger ICEs (which we want to fix > but there will always be some), or run into some compile time and/or compile > memory issue (we have various quadratic or worse spots), compiler stack > limits (deeply nested stuff e.g. during parsing but other areas as well). > So, people running fuzzers and reporting issues is great, but if they'd get > a CVE assigned for each ice-on-invalid-code, ice-on-valid-code, > each compile-time-hog and each memory-hog, that wouldn't be useful. This! Double-this! FWIW, the binutils security policy, and by extension the proposed GCC policy David posted, handles this. (To me this is the most important aspect of such policy, having been on the receiving end of such nonsense on the binutils side). > Runtime libraries or security issues in the code we generate for valid > sources are of course a different thing. Generate or otherwise provide for consumption. E.g. a bug with security consequences in the runtime libs (either in source form (templates) or as executable code, but with the problem being in e.g. libgcc sources (unwinder!)) needs proper handling, similar to how glibc is handled. Ciao, Michael.
