Re: New signing key
Hi, Leo Famulari writes: > Hello, > > I'm changing my Guix signing key from > B0515948F1E7D3C1B98038A02646FA30BACA7F08 to > 68407224D3A64EE53EAC6AAC1963757F47FF. > > Patches to follow. Testing is appreciated! Thanks for the heads-up! -- Thanks, Maxim
Re: New signing key
Hi Tobias, On Tue, 29 Jun 2021 at 16:40, Tobias Geerinckx-Rice wrote: > 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? > :-) Yes, it will be really helpful, I guess. :-) Cheers, simon
Re: New signing key
Hello, Tobias Geerinckx-Rice skribis: > 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 had missed this message, but I think it’s a good idea! Your message is already a good start at that. Thanks, Ludo’.
Re: New signing key
Hi Tobias, On Tue, 2021-06-29 at 16:40 +0200, Tobias Geerinckx-Rice wrote: > 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 think this would be very nice. Especially if it laid out some of the trade-offs as you did here. > > I don't think most people *insist* on their current one, it's just > what they know; and GPG is complex and gnarly. > ... > > 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! > No, I definitely fall into the group who don't insist on a strategy and are just doing what they know :). I appreciate your feedback! And I'll probably be making some adjustments to my workflow. Thanks, `~Eric signature.asc Description: This is a digitally signed message part
Re: New signing key
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 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 signature.asc Description: PGP signature
Re: New signing key
Hi, Eric Bavier 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’.
Re: New signing key
On Wed, 2021-06-23 at 15:48 +0200, Ludovic Courtès wrote: > Hi, > > Apologies for the delay! > > Eric Bavier skribis: > > > I've updated my GPG key on Savannah with a new signing subkey and uid. > > Done in 3694c0d4fee0f7faf130ecd9386ea45932a19543. Thank you Thank you! > 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. > > Anyway, you should be able to push to ‘master’ now. Please double-check > with ‘guix git authenticate’ (and the pre-push hook) that everything’s > fine. Will do. > > > Could a maintainer do the necessary repo updates? > > Note that any committer who’s checked that all is fine can do this, but > I guess everyone was busy hacking (or reviewing!). ;-) I completely understand. I didn't trust myself to know how to check that all is fine. :) > > 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. Thanks again, `~Eric signature.asc Description: This is a digitally signed message part
Re: New signing key
Hi, Apologies for the delay! Eric Bavier skribis: > I've updated my GPG key on Savannah with a new signing subkey and uid. Done in 3694c0d4fee0f7faf130ecd9386ea45932a19543. 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? Anyway, you should be able to push to ‘master’ now. Please double-check with ‘guix git authenticate’ (and the pre-push hook) that everything’s fine. > Could a maintainer do the necessary repo updates? Note that any committer who’s checked that all is fine can do this, but I guess everyone was busy hacking (or reviewing!). ;-) 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. Thanks, Ludo’. signature.asc Description: PGP signature
Re: New signing key
On Tue, 2021-06-15 at 03:05 +, Eric Bavier wrote: > Hello Guix, > > I've updated my GPG key on Savannah with a new signing subkey and uid. > Could a maintainer do the necessary repo updates? Ping? > > Thanks, > `~Eric signature.asc Description: This is a digitally signed message part
Re: New Signing Key
Guix, Brett Gilio 写道： As per my email a few days ago, I have lost control of my signing key. I have, as per instructions, refreshed the key on Savannah and am signing this email. I've authorised Brett in commit ba1d9680d61d3b06d9b81a81863448f494d654a7. Kind regards, T G-R signature.asc Description: PGP signature
Re: New signing key
Roel, Roel Janssen 写道： I am trying to find the revocation key (printed) to revoke the old key as reassurance that I am still me, and no malice is going on. As I moved twice since printing and securely storing the revocation key, this will take some time. Thanks for taking the time to do that! It is appreciated. Is there perhaps a key-signing party for GNU Guix maintainers to build a better trust in the future? We should do something like that at FOSDEM next year. I hope you'll be able to attend. Kind regards, T G-R signature.asc Description: PGP signature
Re: New signing key
Hello Ludo’ and Guix, I lost the password of the old key. I updated my OpenPGP key on Savannah to the new one (F556FD94FB8F8B8779E36832CBD0CD5138C19AFC). I am trying to find the revocation key (printed) to revoke the old key as reassurance that I am still me, and no malice is going on. As I moved twice since printing and securely storing the revocation key, this will take some time. Is there perhaps a key-signing party for GNU Guix maintainers to build a better trust in the future? Kind regards, Roel Janssen On Thu, 2020-03-05 at 18:13 +0100, Ludovic Courtès wrote: > Hello Roel, > > You signed commit cc51c03ff867d4633505354819c6d88af88bf919 and its > parent with OpenPGP key F556FD94FB8F8B8779E36832CBD0CD5138C19AFC, > which > differs from the one registered in ‘build-aux/git-authenticate.scm’ > (17CB 2812 EB63 3DFF 2C7F 0452 C3EC 1DCA 8430 72E1) that you used > previously. > > Could you please reply to this message signed with the old key, > stating > that the new key is the right one? > > As a last resort, if you lost control of the old key, could you > ensure > your Savannah account contains the new key and send a reply signed > with > the new key? > > Thanks in advance, > Ludo’. signature.asc Description: This is a digitally signed message part
