Question: I think committers should be trusted with discretion in 
how they prefer to manage their keys, but how about briefly 
documenting a suggested sane key-management strategy to new 
committers, like we already describe some rando's editor set-up? 
:-)

I don't think most people *insist* on their current one, it's just 
what they know; and GPG is complex and gnarly.

Eric Bavier <bavier@posteo.net> skribis:
> In this case, the old key had already expired.  I think others 
> here
> have reset the expiry date on their keys before?

Limiting validity to 1…2y is considered good hygiene, as is simply 
extending the date whenever it's about to expire.  It proves you 
still control the private key.  It doesn't matter if you miss the 
deadline.

It's what I'd suggest for Guix because it gives committers full 
control over renewal without the inherent risk of updating the 
keyring & .guix-authorizations each time.  It also makes such 
commits less routine, which I think is good…

> I like the idea of honoring the expiration dates I set

Excellent, but ^ this…

> and creating a new key.

…doesn't imply ^ this.

Signing your existing key with a new expiry date is just as 
honourable^Wsecure, and much less hassle.  You would have avoided 
the delay you encountered here.  Others would get a better error 
message (‘expired’ vs. now ‘unknown’).  Etc.

I'm not aware of any authority on best practices that would claim 
the opposite, but if you are, I'd be grateful to hear about it!

Kind regards,

T G-R