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? |