How can Autoconf help with the transition to stricter compilation defaults?

[Aaron Ballman via cfe-commits]

On Tue, Nov 15, 2022 at 3:27 PM Paul Eggert <eggert at cs.ucla.edu> 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