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 D0115138334 for ; Tue, 4 Dec 2018 10:07:04 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C7BEBE0BF6; Tue, 4 Dec 2018 10:07:03 +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 7A487E0BCB for ; Tue, 4 Dec 2018 10:07:03 +0000 (UTC) Received: from 5e46-fe7f-49ff-6ef0-e280-83b6-07d0-2001.dyn.estpak.ee (5e46-fe7f-49ff-6ef0-e280-83b6-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:83b6:e280:6ef0:49ff:fe7f:5e46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: leio) by smtp.gentoo.org (Postfix) with ESMTPSA id 550A2335C02 for ; Tue, 4 Dec 2018 10:07:01 +0000 (UTC) Message-ID: <1543918014.24851.7.camel@gentoo.org> Subject: Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items - Council meeting 2018-12-09 From: Mart Raudsepp To: gentoo-project@lists.gentoo.org Date: Tue, 04 Dec 2018 12:06:54 +0200 In-Reply-To: <1c00c4da-8369-6539-2156-cf5b4375976e@gentoo.org> References: <1543149110.17973.1.camel@gentoo.org> <2a393e89-3156-9666-de46-2faf2fd1f7e3@gentoo.org> <20181204001604.GK16376@monkey> <1543894892.810.5.camel@gentoo.org> <1c00c4da-8369-6539-2156-cf5b4375976e@gentoo.org> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-kI+uuFL9gGx9knyKtK7H" X-Mailer: Evolution 3.26.6 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply Mime-Version: 1.0 X-Archives-Salt: ccf19003-bf6d-4d80-a851-49ce00a953f2 X-Archives-Hash: ce7839f3945f0c00a2c3fbd1f6f9b8a1 --=-kI+uuFL9gGx9knyKtK7H Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =C3=9Chel kenal p=C3=A4eval, T, 04.12.2018 kell 10:54, kirjutas Kristian Fiskerstrand: > On 12/4/18 4:41 AM, Micha=C5=82 G=C3=B3rny wrote: > > Are you asking the Council to make a policy for security team, > > or to override the existing policy of security team? Because this > > sounds like you're implying that security team can't make up their > > mind. >=20 > This is indeed part of the ongoing discussion surrounding the GLEP > for > the security team; Before anything should go to council on this we > need > to put the the current draft up for a public discussion on the > -project > mailing list. >=20 > >=20 > > Also, if the Council votes 'yes', what happens next? Does security > > accept all stable arches? Do stable arches get demoted implicitly > > based > > on security project considerations? >=20 > The assumption would be that security needs to have a say for > whenever > an arch is added or if requesting to remove an arch. To balance this > a a > GLEP48-style/QA-style lead approval process is added and criteria to > be > used for such determination is included. >=20 > Personally I don't see a problem with the status quo where security > supported arches is listed as part of security project's > documentation, > and removals announced etc. The actual security implication for a lot > of > these arches will anyways be impacted by members of the team having > limited knowledge of particulars, in particular when it come to > auditing > due to difference in assembly etc, so the major arches will anyways > have > a better foundation for being handled by the team, so security is > relative to what we claim to know and do. >=20 > In any case, too early for the council to do anything here. Given this subthread and the points about GLEP, I'm not sure how we can discuss these things without even having seen the security GLEP update proposal yet. Thus I will not add these items to the agenda (we can also call them proposed over a day late, if you want), but rather explicitly bring out the open bug about the GLEP update, as it keeps getting delayed from meeting to meeting. Hopefully this (and it being a prerequisite for the "rejected" agenda items) brings more attention to it and at least something becomes ready and appears to the public. That said, I would very much welcome b-man with this topic to the open floor. Mart --=-kI+uuFL9gGx9knyKtK7H Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQKTBAABCgB9FiEEUdZn9pOq0mlNjRvdEKbJ+k9JlgYFAlwGUb5fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDUx RDY2N0Y2OTNBQUQyNjk0RDhEMUJERDEwQTZDOUZBNEY0OTk2MDYACgkQEKbJ+k9J lgZiIBAArFNdZA27r5TKm3wIgS9zuEHE6wnaIqt9XetkVXbAErkNi34QZ3oQvsSl z/qNiJFORo7gFd+c7TxMMbYAxcH9/O+XzDUm1n44dfi2BORPK4OOGDTXcQYvM3ZB 1Bzu0lFr16dono0t/fMKckERcs6GUrYZXa6XVw2MOjFfBeo8ExQ5tvqpKGfTsOy2 iBEQYzxFmMupkMQTeEF2oHbh8rY/lCZPlmm8qt4mo0M/hApXnMTeOPXVdCNYIm0R Q+6W++W7uxj8/52n1y4tCIRhnUXHji20Kx4wraFnIguR2Kp/o5VqbRSHhueq5JJO 3X1SxHrsA9RVw4TATJLQ1B+tX81mnuBJ+mY4mJnKCnLZZguXYEwVHxRX0h/oiYYy q/WOl8GxQD1Vge2TB21yHNieEuCesrXctutCWeeY0po6ejsBnuINViHNMGVWIfHF 5WfnyycCBqv4ydxc9pebkggH/T8+BmeBom6MwxL9lksKYwntomP6E9kFpSZAs5ps nbnU7IGQ1zKM1om63/OpKn0ZQZjWor3A8m1TSuqEyVa/NRnPDm5A1w/q52+g2bGX r9Yvo5rA4Exzy1nVkWL+9JU3es8vg3SyDk/ZcVvt9b6Wv+Dox1hUbqYcANUkoBuy QLnjQH9ertlO/XioAdTX1JdzDHbKAQOW8DwbqAcC5KguLKChTdI= =W1Rf -----END PGP SIGNATURE----- --=-kI+uuFL9gGx9knyKtK7H--