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 766C71382C5 for ; Thu, 17 Dec 2020 04:50:39 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5D181E0993; Thu, 17 Dec 2020 04:50:35 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.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 AEC3DE097A for ; Thu, 17 Dec 2020 04:50:34 +0000 (UTC) Subject: Re: [gentoo-dev] GPG key refresh To: gentoo-dev@lists.gentoo.org, =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= 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> <964d75d0efb69fab4d00d4ad44ce0d3dfd17a0ec.camel@gentoo.org> From: desultory Message-ID: <6f91bf25-1f22-776a-e4b8-953965e8f7fd@gentoo.org> Date: Wed, 16 Dec 2020 23:48:14 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 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 In-Reply-To: <964d75d0efb69fab4d00d4ad44ce0d3dfd17a0ec.camel@gentoo.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Archives-Salt: 74e1558a-59fd-4e4f-a7bd-d80a16f055d4 X-Archives-Hash: 0f0a89b07661a7a9228bdf966fe7ee77 On 12/16/20 03:01, Michał Górny wrote: > 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? > Discuss it, which is more than you have done here. There is no need to berate signal because you feel like making noise. Formulating and discussing ways to fix problems before actually fixing them helps to reduce effort wasted on rebuilding old solutions which have failed for whatever reason. In this case documentation needs to be updated, discussing the appropriate manner in which to update which documentation seems to be more grounds for engagement than recrimination. On the subject of updating the documentation, the proposal seems generally sound; do you have any constructive criticism of it?