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 93D471396D0 for ; Wed, 13 Sep 2017 08:04:11 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D67B3E0BF9; Wed, 13 Sep 2017 08:04:05 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 82CF3E0BEF for ; Wed, 13 Sep 2017 08:04:05 +0000 (UTC) Received: from sf (host81-129-83-128.range81-129.btcentralplus.com [81.129.83.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: slyfox) by smtp.gentoo.org (Postfix) with ESMTPSA id 5059333BF1C; Wed, 13 Sep 2017 08:04:02 +0000 (UTC) Date: Wed, 13 Sep 2017 09:03:44 +0100 From: Sergei Trofimovich To: gentoo-dev@lists.gentoo.org, bman@gentoo.org Cc: Ulrich Mueller , security@gentoo.org Subject: Re: [gentoo-dev] Re: On dropping sparc@ from CC on bugs Message-ID: <20170913090344.0adcbede@sf> In-Reply-To: <22968.55158.799187.902608@a1i15.kph.uni-mainz.de> References: <20170911084313.2cf9f40e@sf> <4481473.IXDqc1jNCF@localhost.localdomain> <22968.55158.799187.902608@a1i15.kph.uni-mainz.de> X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; 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: multipart/signed; micalg=pgp-sha1; boundary="Sig_/IdGm8gn1njKdiQXUyNnY4UZ"; protocol="application/pgp-signature" X-Archives-Salt: d1f17a2a-9055-414b-88a4-f52364e89c2b X-Archives-Hash: 990272abf111b98020382f73e2f87211 --Sig_/IdGm8gn1njKdiQXUyNnY4UZ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 13 Sep 2017 09:00:06 +0200 Ulrich Mueller wrote: > >>>>> On Tue, 12 Sep 2017, Matt Turner wrote: =20 >=20 > > I suggested that when security bugs are complete, that if there are > > exp architectures still Cc'd, that security simply reassign to the > > maintainer and let the bug continue as a regular stabilization bug. =20 >=20 > > Unfortunately Aaron says that this is far too much work -- the hassle > > of reassigning a bug and all. =20 >=20 > Let's look at the security team's own policy on that (thanks to K_F > for pointing me to it): > https://wiki.gentoo.org/wiki/Project:Security/GLSA_Coordinator_Guide#Bugs= _in_.5Bstable.5D_status >=20 > | All arches (including "unsupported" arches) must be called. But note > | that only "supported" arches (as defined in the policy) are needed > | before the bug can advance to [glsa] status >=20 > Note that it says "unsupported arches", not "unsupported arches with a > stable profile". In fact, the whole guide doesn't mention profiles at > all. >=20 > The alternative scenario would be only to add supported arches to the > security bug. This would mean that the maintainer had to open a second > bug for stabilisation on unsupported arches (which includes not only > arches with experimental profiles, but also stable ones like arm). > Maybe that would take away some hassle from the security team, but it > would certainly mean more work for both maintainers and arch teams. Thanks for spelling the question out! [ CC security@, CC bman@ explicitly ] Aaron, can you clarify on it how you perceive the rules on security side? It's very hard to get a coherent picture from short sentences on IRC, bugs and email. Here is what information I see: [irc/#gentoo-council]: 02:08:42 <+b-man> slyfox: security bugs do not require cc'ing unstable arches or non-security supported arches [bug/630680#c7]: No, it is not longer security supported and is not a stable arch. [mail] : You're right. Fixed. and I can't infer anything at all from it! Does it mean normal STABLEREQ for exp arches should never be reassigned to security bug of because their notion of exp arch is different from arch team's? If it's a documented rule link would help here. My intention to post to -dev@ was specifically to clarify the rules for everyone to decrease hassle and misunderstanding. Not to increase it. https://bugs.gentoo.org/show_bug.cgi?id=3D630680#c7 is an example of incomplete answer that does not give any more information to me. The comments above imply sparc@ does not care about stable keywords. sparc@ does care about stable keywords but does not want to make it a burden on other teams. Why CC clarity is important here? Understanding the security workflow would help here: Do you never close any security bug that has any arch CCed? (Is there a policy around that?) Do you never proceed with GLSA if there is any arch CCed? (Stable or not) What do you do if there is not only arches in CC but normal people or other projects? Does it impede the process? Thanks! --=20 Sergei --Sig_/IdGm8gn1njKdiQXUyNnY4UZ Content-Type: application/pgp-signature Content-Description: Цифровая подпись OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSZKa0VG5avZRlY01hxoe52YR/zqgUCWbjmYQAKCRBxoe52YR/z qi95AJ9JpqhmudBndpAlOY49tNWTNPmulwCeIKe2zLBFEASOgaK6W3sNZa2W9VQ= =ITbV -----END PGP SIGNATURE----- --Sig_/IdGm8gn1njKdiQXUyNnY4UZ--