[gentoo-dev] GPG key refresh

[gentoo-dev] GPG key refresh

[Michael Orlitzky]

I'm still getting this,

   $ git push --signed
   ...
   remote: 1C49724D229E93A2 [Michael Orlitzky <mjo@gentoo.org>] [E]
   expire:short Expiration date is too close, please renew (is 2020-12-26
   23:30:47, less than 14 days)
   remote: 1C49724D229E93A2:6F48D3DA05C2DADB [Michael Orlitzky
   <mjo@gentoo.org>] [E] expire:short Expiration date is too close,
   please renew (is 2020-12-26 23:31:43, less than 14 days)

over a week after I've renewed my keys. The answer I get back from the 
keyserver(s) looks OK:

   $ gpg --search-keys 0x6F48D3DA05C2DADB
   gpg: data source: http://85.25.207.23:11371
   (1)   Michael Orlitzky <mjo@gentoo.org>
         Michael Orlitzky <michael@orlitzky.com>
           4096 bit RSA key 0x1C49724D229E93A2, created: 2010-03-17,
           expires: 2022-12-05


Did I forget a step? How long should it take for infra to refresh?

Re: [gentoo-dev] GPG key refresh

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 1555 bytes --]

antarus@woodpecker ~ $ gpg --keyserver hkps://keys.gentoo.org --search-keys
1C49724D229E93A2
gpg: data source: https://[2001:470:ea4a:1:230:48ff:fef8:9fdc]:443
(1)     Michael Orlitzky <mjo@gentoo.org>
       Michael Orlitzky <michael@orlitzky.com>
         4096 bit RSA key 1C49724D229E93A2, created: 2010-03-17, expires:
2020-12-26
Keys 1-1 of 1 for "1C49724D229E93A2".  Enter number(s), N)ext, or Q)uit > q
gpg: error searching keyserver: Operation cancelled
gpg: keyserver search failed: Operation cancelled

I think you need to push to hkps://keys.gentoo.org

-A

On Mon, Dec 14, 2020 at 11:00 AM Michael Orlitzky <mjo@gentoo.org> wrote:

> I'm still getting this,
>
>    $ git push --signed
>    ...
>    remote: 1C49724D229E93A2 [Michael Orlitzky <mjo@gentoo.org>] [E]
>    expire:short Expiration date is too close, please renew (is 2020-12-26
>    23:30:47, less than 14 days)
>    remote: 1C49724D229E93A2:6F48D3DA05C2DADB [Michael Orlitzky
>    <mjo@gentoo.org>] [E] expire:short Expiration date is too close,
>    please renew (is 2020-12-26 23:31:43, less than 14 days)
>
> over a week after I've renewed my keys. The answer I get back from the
> keyserver(s) looks OK:
>
>    $ gpg --search-keys 0x6F48D3DA05C2DADB
>    gpg: data source: http://85.25.207.23:11371
>    (1)   Michael Orlitzky <mjo@gentoo.org>
>          Michael Orlitzky <michael@orlitzky.com>
>            4096 bit RSA key 0x1C49724D229E93A2, created: 2010-03-17,
>            expires: 2022-12-05
>
>
> Did I forget a step? How long should it take for infra to refresh?
>
>

[-- Attachment #2: Type: text/html, Size: 2833 bytes --]

Re: [gentoo-dev] GPG key refresh

[Cédric Krier]

[-- Attachment #1: Type: text/plain, Size: 1200 bytes --]

On 2020-12-14 13:59, Michael Orlitzky wrote:
> I'm still getting this,
> 
>    $ git push --signed
>    ...
>    remote: 1C49724D229E93A2 [Michael Orlitzky <mjo@gentoo.org>] [E]
>    expire:short Expiration date is too close, please renew (is 2020-12-26
>    23:30:47, less than 14 days)
>    remote: 1C49724D229E93A2:6F48D3DA05C2DADB [Michael Orlitzky
>    <mjo@gentoo.org>] [E] expire:short Expiration date is too close,
>    please renew (is 2020-12-26 23:31:43, less than 14 days)
> 
> over a week after I've renewed my keys. The answer I get back from the 
> keyserver(s) looks OK:
> 
>    $ gpg --search-keys 0x6F48D3DA05C2DADB
>    gpg: data source: http://85.25.207.23:11371
>    (1)   Michael Orlitzky <mjo@gentoo.org>
>          Michael Orlitzky <michael@orlitzky.com>
>            4096 bit RSA key 0x1C49724D229E93A2, created: 2010-03-17,
>            expires: 2022-12-05
> 
> 
> Did I forget a step? How long should it take for infra to refresh?

You must pipe the "gpg --export" of your key to openpgp-key-upload when
connected to dev.gentoo.org like:

    gpg --export <your key> | ssh dev.gentoo.org /usr/local/bin/openpgp-key-upload

-- 
Cédric Krier

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 506 bytes --]

Re: [gentoo-dev] GPG key refresh

[Michael Orlitzky]

On 12/14/20 2:17 PM, Alec Warner wrote:
> 
> I think you need to push to hkps://keys.gentoo.org <http://keys.gentoo.org>
> 

Ok, did that. The error message specifically states,

   remote: *** None of your keys comply with GLEP 63.

and GLEP63 says to upload your keys to the SKS keyservers. Does the GLEP 
need an update? I guess we never resumed fetching from them after the 
incident?

RE: [gentoo-dev] GPG key refresh

[Thomas Deutschmann]

[-- Attachment #1: Type: text/plain, Size: 447 bytes --]

Hi,

what exactly did you do already?

Did you uploaded to our internal key server? You can only upload through dev.gentoo.org, see https://wiki.gentoo.org/wiki/Project:Infrastructure/Generating_GLEP_63_based_OpenPGP_keys#Submit_your_new_key_to_the_keyserver

However, you can pull from this server.

I tried to test your key but I am currently getting a failure from our keyserver. Waiting for infra to check.


-- 
Regards,
Thomas

[-- Attachment #2: openpgp-digital-signature.asc --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

Re: [gentoo-dev] GPG key refresh

[Michael Orlitzky]

On 12/15/20 10:27 AM, Thomas Deutschmann wrote:
> Hi,
> 
> what exactly did you do already?
> 
> Did you uploaded to our internal key server? You can only upload
> through dev.gentoo.org, see
> https://wiki.gentoo.org/wiki/Project:Infrastructure/Generating_GLEP_63_based_OpenPGP_keys#Submit_your_new_key_to_the_keyserver
>
>  However, you can pull from this server.
> 
> I tried to test your key but I am currently getting a failure from
> our keyserver. Waiting for infra to check.
> 

It's working now. I hadn't pushed directly to the internal server, 
unaware that it was still internal. An update to the error message (git 
hook) that mentions that wiki page could mitigate similar headaches in 
the future. GLEP63 still says,

   == Bare minimum requirements ==
   ...
     7. Upload your key to the SKS keyserver rotation before usage!

which should also be amended if there's no imminent plan to resume 
pulling keys from there.

Re: [gentoo-dev] GPG key refresh

[Michael Orlitzky]

On 12/15/20 10:27 AM, Thomas Deutschmann wrote:
>  https://wiki.gentoo.org/wiki/Project:Infrastructure/Generating_GLEP_63_based_OpenPGP_keys#Submit_your_new_key_to_the_keyserver
> 

And FWIW this sentence is a little misleading if the SKS refresh 
frequency is zero =)

   The SKS keyserver pool can take much longer to replicate over the
   keyserver network, while the Gentoo developer tooling explicitly
   checks the Gentoo keyserver pool with a much higher frequency.

RE: [gentoo-dev] GPG key refresh

[Thomas Deutschmann]

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

Hi,

glad it's now working for you. In the meanwhile we are looking into issues with the European Gentoo server 😉


> And FWIW this sentence is a little misleading if the SKS refresh 
> frequency is zero =)
> 
>    The SKS keyserver pool can take much longer to replicate over the
>    keyserver network, while the Gentoo developer tooling explicitly
>    checks the Gentoo keyserver pool with a much higher frequency.

What do you mean exactly?

For Gentoo tooling, only Gentoo keyservers are important and Gentoo no longer synchronizes with any other pool.

However, developers should still upload keys to public pools, like the SKS keyservers, so others can find the key in case they want to verify checksum or securely exchange encrypted/signed messages with Gentoo developers.


-- 
Regards,
Thomas

[-- Attachment #2: openpgp-digital-signature.asc --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

Re: [gentoo-dev] GPG key refresh

[Michael Orlitzky]

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.

Re: [gentoo-dev] GPG key refresh

[Aaron W. Swenson]

[-- Attachment #1: Type: text/plain, Size: 2639 bytes --]

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.


Footnotes:
[1]  https://www.gentoo.org/glep/glep-0063.html

[2]  https://wiki.gentoo.org/index.php?title=Project:Infrastructure/Generating_GLEP_63_based_OpenPGP_keys&oldid=813494#Submit_your_new_key_to_the_keyserver

[3]  https://www.gentoo.org/news/2019/07/03/sks-key-poisoning.html


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] GPG key refresh

[Michał Górny]

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

Re: [gentoo-dev] GPG key refresh

[desultory]

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?

Re: [gentoo-dev] GPG key refresh

[Mike Gilbert]

On Wed, Dec 16, 2020 at 11:48 PM desultory <desultory@gentoo.org> wrote:
>
> 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?
>

So I can understand where Michał's reaction comes from. On my first
read through Aaron's message, it seemed like a long email complaining
about things that had been done wrong. Upon re-reading it with a
different mindset, it doesn't seem so bad if you skip over some of the
text.

For example, I don't think the paragraph below is necessary, and could
evoke a defensive reaction from the recipient.

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

I think a shorter email simply requesting that the documentation be
updated would have sufficed.

Re: [gentoo-dev] GPG key refresh

[Mike Gilbert]

On Wed, Dec 16, 2020 at 3:01 AM Michał Górny <mgorny@gentoo.org> 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?

If you think he's being unhelpful, maybe suggest ways of contributing
that would be more helpful. There's no need for this snippy reply.

Re: [gentoo-dev] GPG key refresh

[Michał Górny]

On Thu, 2020-12-17 at 13:35 -0500, Mike Gilbert wrote:
> On Wed, Dec 16, 2020 at 3:01 AM Michał Górny <mgorny@gentoo.org>
> 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?
> 
> If you think he's being unhelpful, maybe suggest ways of contributing
> that would be more helpful. There's no need for this snippy reply.
> 

Are you suggesting that a developer with almost 10 years of experience
in Gentoo doesn't know how to file a bug?  The likeliness of me reading
that particular mail in middle of the thread was really low.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] GPG key refresh

[Michał Górny]

On Thu, 2020-12-17 at 13:28 -0500, Mike Gilbert wrote:
> On Wed, Dec 16, 2020 at 11:48 PM desultory <desultory@gentoo.org>
> wrote:
> > 
> > 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?
> > 
> 
> So I can understand where Michał's reaction comes from. On my first
> read through Aaron's message, it seemed like a long email complaining
> about things that had been done wrong. Upon re-reading it with a
> different mindset, it doesn't seem so bad if you skip over some of
> the
> text.

To me, it sounded like 'I am so important that I can't be bothered to
report it properly, so I just write a long complaint right here
and expect someone to resolve it'.


-- 
Best regards,
Michał Górny