Gentoo Archives: gentoo-dev

From: Richard Yao <ryao@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Changing policy about -Werror
Date: Sun, 09 Sep 2018 17:24:19
Message-Id: 6AA4D38E-BFE8-429C-B532-4CADC00F588E@gentoo.org
In Reply to: Re: [gentoo-dev] Changing policy about -Werror by Richard Yao
1 > On Sep 9, 2018, at 1:09 PM, Richard Yao <ryao@g.o> wrote:
2 >
3 >
4 >
5 >> On Sep 9, 2018, at 12:11 PM, Michał Górny <mgorny@g.o> wrote:
6 >>
7 >> On Sun, 2018-09-09 at 11:22 -0400, Richard Yao wrote:
8 >>>> On Sep 9, 2018, at 7:32 AM, Andrew Savchenko <bircoph@g.o> wrote:
9 >>>>
10 >>>> Hi!
11 >>>>
12 >>>> Our current -Werror policy demands unconditional removal:
13 >>>> https://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html#-werror-compiler-flag-not-removed
14 >>>>
15 >>>> I think this is wrong, see bugs 665464, 665538 for a recent
16 >>>> discussion why.
17 >>>>
18 >>>> My point is that in *most* cases -Werror indeed should be removed,
19 >>>> because upstream rarely can keep up with all possible configure,
20 >>>> *FLAGS, compiler versions and arch combinations. But! In some cases
21 >>>> — especially for security oriented software — this flag may be
22 >>>> pertain and may be kept at maintainer's discretion.
23 >>>>
24 >>>> The rationale is that -Werror usually points to dangerous
25 >>>> situations like uninitialized variables, pointer type mismatch or
26 >>>> implicit function declaration (and much more) which may lead to
27 >>>> serious security implications.
28 >>>>
29 >>>> So, if maintainer has enough manpower to support this flag, we
30 >>>> should allow to keep it. Of course if it will cause long-standing
31 >>>> troubles (e.g. bugs opened for a long time) QA should have power to
32 >>>> remove it or demand its removal.
33 >>>>
34 >>>> So my proposal is:
35 >>>>
36 >>>> 1) Deprecate QA policy with unconditional demand of -Werror removal.
37 >>>> 2) Add to devmanual's chapter on -Werror an exception clause about
38 >>>> security-oriented software and maintainer's right to make final
39 >>>> decision.
40 >>>
41 >>> -Werror has caught bugs that could have resulted in data loss in ZFS in the past thanks to it being built in userspace as part of zdb. So it is useful for integrity too, not just security (although arguably, integrity is part of security).
42 >>>
43 >>> Currently, sys-fs/zfs turns on -Werror when USE=debug is set. So far, nobody has complained about USE=debug enforcing -Werror. USE=debug by definition ought to be an exception.
44 >>
45 >> Now that you know that you're violating a policy, please kindly fix
46 >> that.
47 > I already knew about the policy. However, USE=debug is by definition meant for debug purposes. -Werror is helpful for debugging. There is nothing wrong with turning it on for debugging. The normal builds don’t have USE=debug set and -Werror is not used there.
48
49 By the way, if people insist on applying this policy to USE=debug, I am inclined to mask the USE flag. This would satisfy the policy, but I don’t think that is better than how things are now. Users already are warned not to set USE=debug globally and if they are setting it on a specific package, they are opting into the package’s definition of debug functionality.
50
51 I don’t see a problem with having -Werror as part of USE=debug. USE=debug on that package is meant to be an aid to upstream development and upstream in this case wants to know about any warnings.
52 >>> Perhaps we could have another USE flag for -Werror where it is a security feature. e.g. USE=strict-compile-checks
53 >>
54 >> Perhaps people could learn that Gentoo lets them alter CFLAGS, and stop
55 >> inventing USE flags for every flag the compiler supports.
56 >>
57 >>>>
58 >>>> Best regards,
59 >>>> Andrew Savchenko
60 >>>
61 >>>
62 >>
63 >> --
64 >> Best regards,
65 >> Michał Górny
66 >
67 >