Hi, Eric Bavier <bav...@posteo.net> skribis:
> On Wed, 2021-06-23 at 15:48 +0200, Ludovic Courtès wrote: [...] >> In >> d1d2bf3eb6ba74b058969756a97a30aec7e0c4d1 I added your new key and >> renamed the old one, but perhaps we can just remove the old one, if the >> old sub-key is still in the new one? > > I think the old key is still there, yes. I didn't remove it, just > added the new key. OK. I removed the former key file from the ‘keyring’ branch in commit 359ca340273213f7bafda455c9f89db55d69849c; I checked with ‘guix git authenticate’ that we can still authenticate former commits. >> In the future, unless you lose control of the key, it’s even better if >> you do it yourself: push a commit signed with the old key that >> introduces the new key. Otherwise we have to trust that you really are >> the one who uploaded the new key on Savannah. > > In this case, the old key had already expired. I think others here > have reset the expiry date on their keys before? I like the idea of > honoring the expiration dates I set, and creating a new key. But I'm > also willing to adopt whatever we decide is a best practice. I think either way is fine. I set an expiry date a few months in the future, and I change it a few weeks before it expires, the idea being that if I lose control of the key (e.g., laptop stolen) it’ll expire not too longer after that. Thanks, Ludo’.