From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 32189138334 for ; Sun, 9 Sep 2018 15:11:34 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B6595E097D; Sun, 9 Sep 2018 15:11:29 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 4FE91E0963 for ; Sun, 9 Sep 2018 15:11:28 +0000 (UTC) Received: from wim.jer (jer.xs4all.nl [212.238.182.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jer) by smtp.gentoo.org (Postfix) with ESMTPSA id E1252340562 for ; Sun, 9 Sep 2018 15:11:26 +0000 (UTC) Date: Sun, 9 Sep 2018 17:11:07 +0200 From: Jeroen Roovers To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Changing policy about -Werror Message-ID: <20180909171107.7b3ec734@wim.jer> In-Reply-To: <20180909143221.21d784d02f51623e8c57c545@gentoo.org> References: <20180909143221.21d784d02f51623e8c57c545@gentoo.org> Organization: Gentoo Foundation X-Mailer: Claws Mail 3.17.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: ab31d7e0-86f3-4d04-a84b-3b4220cca63e X-Archives-Hash: 0d25e3017bfac3b3e2a9e1cf74b09a28 On Sun, 9 Sep 2018 14:32:21 +0300 Andrew Savchenko wrote: > Hi! >=20 > Our current -Werror policy demands unconditional removal: > https://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html#-w= error-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 > =E2=80=94 especially for security oriented software =E2=80=94 this flag m= ay 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=3D (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. >=20 > 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. >=20 > So my proposal is: >=20 > 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.=20 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.