On Tue, Nov 15, 2022 at 3:27 PM Paul Eggert <eggert@xxxxxxxxxxx> wrote: > > On 2022-11-15 11:27, Jonathan Wakely wrote: > > Another perspective is that autoconf shouldn't get in the way of > > making the C and C++ toolchain more secure by default. > > Can you cite any examples of a real-world security flaw what would be > found by Clang erroring out because 'char foo(void);' is the wrong > prototype? Is it plausible that any such security flaw exists? CVE-2006-1174 is a possibly reasonable example. That one is specifically about the K&R C open() interface, but the reason the CVE happened was because a required argument was not passed which is exactly the kind of problem you'd get from a prototype mismatch. I think autoconf's usage pattern is well outside of common C coding practices. Most folks who call a function expect the call to plausibly happen at runtime (rather than do so just to see if the linker will complain or not), and I don't know of another context in which anyone expects calling a function with an incorrect signature will lead to good outcomes. > On the contrary, it's more likely that Clang's erroring out here would > *introduce* a security flaw, because it would cause 'configure' to > incorrectly infer that an important security-relevant function is > missing and that a flawed substitute needs to be used. > > Let's focus on real problems rather than worrying about imaginary ones. If the symbol exists and `configure` says it does not, that's the bug and it's not with the host compiler. You can run into that same bug with use of `-Werror`, as others have pointed out. So strengthening warnings doesn't introduce any NEW problems into autoconf, it exacerbates existing ones. ~Aaron
