patchconfig.mak.dev: add -Wformat-security

We currently build cleanly with -Wformat-security, and it's a good idea to make sure we continue to do so (since calls that trigger the warning may be security vulnerabilities).

Note that we cannot use the stronger -Wformat-nonliteral, as there are case where we are clever with passing around pointers to string literals. E.g., bisect_rev_setup() takes bad_format and good_format parameters. These ultimately come from literals, but they still trigger the warning.

Some of these might be fixable (e.g., by passing flags from which we locally select a format), and might even be worth fixing (not because of security, but just because it's an easy mistake to pass the wrong format). But there are other cases which are likely quite hard to fix (we actually generate formats in a local buffer in some cases). So let's punt on that for now and start with -Wformat-security, which is supposed to catch the most important cases.

Signed-off-by: Jeff King <peff@peff.net>
---
 config.mak.dev | 1 +
 1 file changed, 1 insertion(+)

On Fri, Sep 7, 2018 at 8:21 PM Jeff King <peff@peff.net> wrote:

Nice. I had this flag in my config.mak too before switching to DEVELOPER=1. Didn't realize I lost the flag until now.

Maybe keep it sorted

On Sat, Sep 08, 2018 at 03:38:19PM +0200, Duy Nguyen wrote:

I thought I used to use it, too, but I realized recently that I never did (I experimented with format-nonliteral a long time ago but gave up).

AFAIK we've never actually had a case that this triggered, because it's so narrow (as opposed to format-nonliteral).

Heh, I didn't even notice the original was sorted. Here it is in the right spot:

-- >8 --
Subject: config.mak.dev: add -Wformat-security

We currently build cleanly with -Wformat-security, and it's a good idea to make sure we continue to do so (since calls that trigger the warning may be security vulnerabilities).

Note that we cannot use the stronger -Wformat-nonliteral, as there are case where we are clever with passing around pointers to string literals. E.g., bisect_rev_setup() takes bad_format and good_format parameters. These ultimately come from literals, but they still trigger the warning.

Some of these might be fixable (e.g., by passing flags from which we locally select a format), and might even be worth fixing (not because of security, but just because it's an easy mistake to pass the wrong format). But there are other cases which are likely quite hard to fix (we actually generate formats in a local buffer in some cases). So let's punt on that for now and start with -Wformat-security, which is supposed to catch the most important cases.

Signed-off-by: Jeff King <peff@peff.net>
---
 config.mak.dev | 1 +
 1 file changed, 1 insertion(+)