Gentoo Archives: gentoo-dev

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

Replies

Subject Author
Re: [gentoo-dev] GPG key refresh "Michał Górny" <mgorny@g.o>