Gentoo Archives: gentoo-dev

From: desultory <desultory@g.o>
To: gentoo-dev@l.g.o, "Michał Górny" <mgorny@g.o>
Subject: Re: [gentoo-dev] GPG key refresh
Date: Thu, 17 Dec 2020 04:50:39
Message-Id: 6f91bf25-1f22-776a-e4b8-953965e8f7fd@gentoo.org
In Reply to: Re: [gentoo-dev] GPG key refresh by "Michał Górny"
1 On 12/16/20 03:01, Michał Górny wrote:
2 > On Tue, 2020-12-15 at 23:37 -0500, Aaron W. Swenson wrote:
3 >> On 2020-12-15 11:16, Michael Orlitzky wrote:
4 >>> On 12/15/20 11:11 AM, Thomas Deutschmann wrote:
5 >>>>
6 >>>> What do you mean exactly?
7 >>>>
8 >>>> For Gentoo tooling, only Gentoo keyservers are important and
9 >>>> Gentoo no longer synchronizes with any other pool.
10 >>>>
11 >>> "The Gentoo developer tooling explicitly checks the Gentoo
12 >>> keyserver
13 >>> pool with a much higher frequency" strongly implies that we check
14 >>> the
15 >>> non-Gentoo pools with a non-zero frequency.
16 >>>
17 >>>
18 >>
19 >> I'm with Michael on this. I've recently experienced this issue myself
20 >> as the
21 >> instruction to upload the key to the Gentoo keyserver is separate
22 >> from the
23 >> GLEP63[1] document. It doesn't matter that the step is documented if
24 >> the Holy
25 >> Tome GLEP63 doesn't mention it. What hint would I have to look for a
26 >> supplemental document to provide that specific step?
27 >>
28 >> According to GLEP 63, uploading to the SKS keyserver is a
29 >> requirement.
30 >> However, it fails to specify which SKS keyserver. In fact, neither
31 >> "SKS" nor
32 >> "keyserver" are defined in GLEP63. Ergo, the natural interpretation
33 >> is *anything*
34 >> that's called an SKS keyserver will satisfy the requirement. As long
35 >> as the
36 >> developer can submit the key, the requirement is met.
37 >>
38 >> Additionally, the supplemental document[2] doesn't say developers
39 >> must upload
40 >> via an internal host, but that devs should upload to both SKS and the
41 >> Gentoo
42 >> keyserver. Yes, it says the Gentoo keyserver is currently restricted
43 >> to syncing
44 >> with "authorized Gentoo hosts", but that's a nonsense phrase and
45 >> unhelpful. It
46 >> assumes I know what the authorized Gentoo hosts are. It doesn't
47 >> clearly state
48 >> what they are. It kind of hints that it will pull from SKS
49 >> eventually, but it
50 >> could take a long time.
51 >>
52 >> I understand we temporarily stopped syncing with the public keyserver
53 >> out of an
54 >> overabundance of caution. However, that shouldn't have been done
55 >> without
56 >> updating every official Gentoo resource regarding how devs should
57 >> handle their
58 >> keys, which as far as I know is only two documents[1,2]. A whopping 2
59 >> documents.
60 >>
61 >> This new (I know it's been around for a year but that doesn't make it
62 >> any less
63 >> new), stricter requirement, should be **explicitly** stated in
64 >> GLEP63, properly
65 >> referencing the justification[3], and linking to the infra
66 >> supplemental
67 >> document. The infra supplemental document needs to then use the
68 >> phrase "must" in
69 >> place of "should" when informing readers to upload to two different
70 >> locations.
71 >
72 > ...and what have you done to resolve the problem, except for making
73 > oververbose complaints and demands in middle of some random thread?
74 >
75 Discuss it, which is more than you have done here. There is no need to
76 berate signal because you feel like making noise.
77
78 Formulating and discussing ways to fix problems before actually fixing
79 them helps to reduce effort wasted on rebuilding old solutions which
80 have failed for whatever reason. In this case documentation needs to be
81 updated, discussing the appropriate manner in which to update which
82 documentation seems to be more grounds for engagement than recrimination.
83
84 On the subject of updating the documentation, the proposal seems
85 generally sound; do you have any constructive criticism of it?

Replies

Subject Author
Re: [gentoo-dev] GPG key refresh Mike Gilbert <floppym@g.o>