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 C083B1382C5 for ; Wed, 16 Dec 2020 08:01:38 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B7806E090E; Wed, 16 Dec 2020 08:01:34 +0000 (UTC) Received: from smtp.gentoo.org (smtp.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 7D78FE08F4 for ; Wed, 16 Dec 2020 08:01:34 +0000 (UTC) Message-ID: <964d75d0efb69fab4d00d4ad44ce0d3dfd17a0ec.camel@gentoo.org> Subject: Re: [gentoo-dev] GPG key refresh From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Date: Wed, 16 Dec 2020 09:01:28 +0100 In-Reply-To: References: <3789ea75-1287-f225-ed58-11d26a440cb0@gentoo.org> <6fac13a0-6e67-0d00-bd11-f1435774a8b1@gentoo.org> <001101d6d2f6$cf6bbae0$6e4330a0$@gentoo.org> <162d8d9f-4325-eb1e-f1cc-042acfb67973@gentoo.org> <001301d6d2fc$fee96af0$fcbc40d0$@gentoo.org> <792e01e5-fe09-f97e-14ae-57d94cb84510@gentoo.org> Organization: Gentoo Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.2 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 X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Archives-Salt: a800e693-db08-43fa-9a9b-b27ec84d39a1 X-Archives-Hash: 79a94f0155598163397d0293d21a6d97 On Tue, 2020-12-15 at 23:37 -0500, Aaron W. Swenson wrote: > On 2020-12-15 11:16, Michael Orlitzky wrote: > > On 12/15/20 11:11 AM, Thomas Deutschmann wrote: > > > > > > What do you mean exactly? > > > > > > For Gentoo tooling, only Gentoo keyservers are important and > > > Gentoo no longer synchronizes with any other pool. > > > > > "The Gentoo developer tooling explicitly checks the Gentoo > > keyserver > > pool with a much higher frequency" strongly implies that we check > > the > > non-Gentoo pools with a non-zero frequency. > > > > > > I'm with Michael on this. I've recently experienced this issue myself > as the > instruction to upload the key to the Gentoo keyserver is separate > from the > GLEP63[1] document. It doesn't matter that the step is documented if > the Holy > Tome GLEP63 doesn't mention it. What hint would I have to look for a > supplemental document to provide that specific step? > > According to GLEP 63, uploading to the SKS keyserver is a > requirement. > However, it fails to specify which SKS keyserver. In fact, neither > "SKS" nor > "keyserver" are defined in GLEP63. Ergo, the natural interpretation > is *anything* > that's called an SKS keyserver will satisfy the requirement. As long > as the > developer can submit the key, the requirement is met. > > Additionally, the supplemental document[2] doesn't say developers > must upload > via an internal host, but that devs should upload to both SKS and the > Gentoo > keyserver. Yes, it says the Gentoo keyserver is currently restricted > to syncing > with "authorized Gentoo hosts", but that's a nonsense phrase and > unhelpful. It > assumes I know what the authorized Gentoo hosts are. It doesn't > clearly state > what they are. It kind of hints that it will pull from SKS > eventually, but it > could take a long time. > > I understand we temporarily stopped syncing with the public keyserver > out of an > overabundance of caution. However, that shouldn't have been done > without > updating every official Gentoo resource regarding how devs should > handle their > keys, which as far as I know is only two documents[1,2]. A whopping 2 > documents. > > This new (I know it's been around for a year but that doesn't make it > any less > new), stricter requirement, should be **explicitly** stated in > GLEP63, properly > referencing the justification[3], and linking to the infra > supplemental > document. The infra supplemental document needs to then use the > phrase "must" in > place of "should" when informing readers to upload to two different > locations. ...and what have you done to resolve the problem, except for making oververbose complaints and demands in middle of some random thread? -- Best regards, Michał Górny