Re: [gentoo-dev] Changing policy about -Werror

[Jeroen Roovers]

On Sun, 9 Sep 2018 14:32:21 +0300
Andrew Savchenko <bircoph@g.o> wrote:

> Hi!
>
> Our current -Werror policy demands unconditional removal:
> https://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html#-werror-compiler-flag-not-removed

Which is great.

> I think this is wrong, see bugs 665464, 665538 for a recent
> discussion why.

That's just QA failing to be human in one report and then again in
another report. It happens all the time and cannot be fixed, so you seem
to instead suggest banning -Werror wrong because some developers think
they can sanely cat-herd -Werror's overreaching effects.

> My point is that in *most* cases -Werror indeed should be removed,
> because upstream rarely can keep up with all possible configure,
> *FLAGS, compiler versions and arch combinations. But! In some cases
> — especially for security oriented software — this flag may be
> pertain and may be kept at maintainer's discretion.
  ^^^^^^^
Pertinent, you meant to say, I assume.

If you really have to support this mistaken (upstream) sense of
security, instead go for -Werror=<warning> (see gcc(1)) i.e. turn very
specific warnings into errors instead of turning _all_ warnings into
errors.

> The rationale is that -Werror usually points to dangerous
> situations like uninitialized variables, pointer type mismatch or
> implicit function declaration (and much more)

No it does not. It merely turns warnings (non-fatal) emitted by the
actual checks into errors (fatal). It does not cause any checks to be
performed or warnings to be issued by itself.

Setting or allowing a blanket -Werror therefore causes innocuous
warnings like this:

   warning: format not a string literal, argument types not checked
   [-Wformat-nonliteral]
   (In other words: FIXME: I didn't check this format because it was not
   a string literal and I cannot yet resolve those into an actual format
   defined elsewhere.*)

and this:

   # hppa2.0-unknown-linux-gnu-gcc -fstack-protector main.c
   cc1: warning: -fstack-protector not supported for this target

into hilarious errors.

To some those might look like succeeding security checks, but they're
really failing sanity checks.

> which may lead to serious security implications.
>
> So, if maintainer has enough manpower to support this flag, we
> should allow to keep it. Of course if it will cause long-standing
> troubles (e.g. bugs opened for a long time) QA should have power to
> remove it or demand its removal.
>
> So my proposal is:
>
> 1) Deprecate QA policy with unconditional demand of -Werror removal.

You have yet to give arguments for its removal. Like, proper and
particular examples of where -Werror benefits everyone. So far I've
seen only some hand-waving of the (in)security banner. 

Unless you meant to say that security is improved when you can't
install the software when of -Werror prevents it from being built,
because then you've already solved the entire problem of the software's
purported vulnerabilities, indeed.

> 2) Add to devmanual's chapter on -Werror an exception clause about
> security-oriented software and maintainer's right to make final
> decision.

That clause will be the laughing stock of the security community.


Regards,
     jer


* We have plenty of bug reports already where one "security researcher"
points out that the build fails when the former warning is triggered
when -Werror is injected, and it might indeed look like a lurking
security issue if it weren't for the fact that the format sanity check
never took place.