[cfe-dev] RFC: default to -Werror=format-security

[Nico Weber via cfe-dev]

I'm with Reid on this. Useful warnings should be on by default, less useful
warnings shouldn't be, and if our warnings are high-signal enough then most
people will look at them.

I think one problem we have for some warnings (probably including
-Wformat-security) is that it's not clear from the warning text what the
problem is. It'd be useful to have some document that for each warning
lists the warning's motivation and common fixes and workarounds. If people
don't understand a warning and just try to shut up the compiler, things
usually don't end well.

For this warning, it'd probably help a lot to add a fixit like Ben
suggested.

On Tue, Feb 16, 2016 at 11:34 AM, Aaron Ballman <aaron at aaronballman.com>
wrote:

> On Tue, Feb 16, 2016 at 2:18 PM, Nico Weber via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
> > On Mon, Feb 15, 2016 at 6:04 PM, Bob Wilson via cfe-dev
> > <cfe-dev at lists.llvm.org> wrote:
> >>
> >> We’ve had a number of requests to make the format-security warning
> default
> >> to an error. This warning complains about a printf-like format string
> that
> >> is not a literal string and is used without any arguments. E.G.:
> >>
> >> format-security.c:4:10: warning: format string is not a string literal
> >> (potentially insecure) [-Wformat-security]
> >>   printf(fmt);
> >>          ^~~
> >> 1 warning generated.
> >>
> >> For background, if the format string can be controlled by external
> input,
> >> the security risk is that it could contain “%” characters and be used to
> >> clobber memory. The alternative is to use a fixed “%s” format, e.g.,
> >> printf(“%s”, fmt).
> >>
> >> This catches real-world security holes, but sometimes people don’t pay
> >> attention to warnings
> >
> >
> > Won't this line of reasoning lead to all useful warnings being in -Werror
> > eventually? Say, forgetting a return statement in a function is also
> "just"
> > a warning...
>
> I would not be opposed to that either. If it leads to an exploitable
> security vulnerability (such as format specifiers, failing to return
> on all control paths, obvious buffer under/overruns, etc), I think we
> should at least consider making it an error. Perhaps it can be
> controlled with a flag (treat-security-diagnostics-as-an-error) that
> is on by default.
>
> ~Aaron
>
> >
> >>
> >> . Promoting this warning to an error by default would get people’s
> >> attention and help motivate them to fix their code. But, the obvious
> >> downside is that it could be disruptive. Existing code might fail to
> build
> >> and would either require source code fixes or build changes to specify
> >> -Wno-error=format-security.
> >>
> >> Opinions?
> >> _______________________________________________
> >> cfe-dev mailing list
> >> cfe-dev at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >
> >
> >
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160216/2e176c88/attachment.html>