Re: Losing signing keys for custom Guix channel
If commit i adds a new signing key to the channel’s authorisations file and commit i+1 is signed with that signing key, then commit i+1 can be used in channel intro. You can’t add a signing key to the authorisations in a commit and sign that same commit with the new key. Is that issue here? Jake On Fri, 29 Mar 2024 at 2:13 pm, wrote: > > > from reading about guix authentication I think the new signing key > > > must be first added to the .guix-authoriations file and that commit > > > must signed with the current signing keys before the new signing > > > key can be used. > > > > Yes, it’s likely the problem; the rest of the description you gave > > elaexuotee looks fine to me. > > > > (No need to rewrite the history; changing the introduction is enough.) > > > > Ludo’. > > Well, the catch 22 is that I've lost the original key and so can only sign > .guix-authorizations with the new one. > > > (No need to rewrite the history; changing the introduction is enough.) > > Without the old key, I'm gathering that a history rewrite is the only way > right > now. Seems like a fresh channel introduction should be enough, but our > current > authorization check appears to look at earlier commits even in that case, > IIUC. > > Maybe forcing history rewrites on key loss is the desired behavior? I'm not > sure. From a client perspective, the only difference is whether or not you > have > to specify --allow-downgrades on the next pull. In either case a channel > intro > update is necessary. > >
Re: Losing signing keys for custom Guix channel
Ludovic Courtès wrote: > elaexuo...@wilsonb.com skribis: > > > Well, the catch 22 is that I've lost the original key and so can only sign > > .guix-authorizations with the new one. > > Ah sorry, I misread the thing I quoted. :-) > > So, you have your new key. You add it to ‘.guix-authorizations’ in a > commit signed with that new key. And then, you make this commit the new > introduction of your channel. > > Does that make sense? > > Ludo’. Makes perfect sense! It's also exactly what I tried and what ends up failing authorization on guix pull.
Re: Losing signing keys for custom Guix channel
elaexuo...@wilsonb.com skribis: > Well, the catch 22 is that I've lost the original key and so can only sign > .guix-authorizations with the new one. Ah sorry, I misread the thing I quoted. :-) So, you have your new key. You add it to ‘.guix-authorizations’ in a commit signed with that new key. And then, you make this commit the new introduction of your channel. Does that make sense? Ludo’.
Re: Losing signing keys for custom Guix channel
Jake wrote: > If commit i adds a new signing key to the channel’s authorisations file and > commit i+1 is signed with that signing key, then commit i+1 can be used in > channel intro. > > You can’t add a signing key to the authorisations in a commit and sign that > same commit with the new key. Is that issue here? I don't think that's completely accurate. My original channel introduction commit is precisely the one creating a .guix-authorizations file with my old key info. I can certainly add an extra signing key to the authorizations; I just can't sign that commit with the old key, since the old key has been lost.
Re: Losing signing keys for custom Guix channel
> > from reading about guix authentication I think the new signing key > > must be first added to the .guix-authoriations file and that commit > > must signed with the current signing keys before the new signing > > key can be used. > > Yes, it’s likely the problem; the rest of the description you gave > elaexuotee looks fine to me. > > (No need to rewrite the history; changing the introduction is enough.) > > Ludo’. Well, the catch 22 is that I've lost the original key and so can only sign .guix-authorizations with the new one. > (No need to rewrite the history; changing the introduction is enough.) Without the old key, I'm gathering that a history rewrite is the only way right now. Seems like a fresh channel introduction should be enough, but our current authorization check appears to look at earlier commits even in that case, IIUC. Maybe forcing history rewrites on key loss is the desired behavior? I'm not sure. From a client perspective, the only difference is whether or not you have to specify --allow-downgrades on the next pull. In either case a channel intro update is necessary.
Re: Losing signing keys for custom Guix channel
Hello, Markku Korkeala skribis: > On Mon, Mar 25, 2024 at 02:41:26PM +0900, elaexuo...@wilsonb.com wrote: [...] >> Here are the changes I've made: >> - New public key added to keyring branch >> - Appended new key fingerprint to .guix-authorizations (at commit X) >> - Update introduction in .config/guix/channels.scm >> - Point to commit X >> - Update openpgp-fingerprint >> >> As a sanity check, I've confirmed that the fingerprint on commit X, the >> fingerprint in .guix-authorizations, and the openpgp-fingerprint in my >> channels.scm are all the same. >> >> What am I missing? > > Hi all, > > from reading about guix authentication I think the new signing key > must be first added to the .guix-authoriations file and that commit > must signed with the current signing keys before the new signing > key can be used. Yes, it’s likely the problem; the rest of the description you gave elaexuotee looks fine to me. (No need to rewrite the history; changing the introduction is enough.) Ludo’.
Re: Losing signing keys for custom Guix channel
> from reading about guix authentication I think the new signing key > must be first added to the .guix-authoriations file and that commit > must signed with the current signing keys before the new signing > key can be used. yep. otherwise anyone with access to the origin git repo could override the commit signature based authentication framework. if you think about it, if there were any options for you to sidestep this situation of a lost key, then any attacker could do the same. i'm afraid your only option is to re-record and re-sign every commit, force-push them, and publish a new channel intro snippet that all your users must copy into their config. alternatively, you *may* be able to simply publish a new channel intro snippet (and convince all your users that it's a genuine situation) that will point to the first new commit that is signed with the new key... but i doubt the contract (nor the implementation) of the authentication code would just silently accept the non-authenticated commits that precede your new channel intro commit. all the best in fixing the situation! -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “’Tis better it be a year later before he can read, than that he should this way get an aversion to learning.” — John Locke (1632–1704), 'Some Thoughts Concerning Education'
Re: Losing signing keys for custom Guix channel
On Mon, Mar 25, 2024 at 02:41:26PM +0900, elaexuo...@wilsonb.com wrote: > Hey devs, > > So I lost the PGP key that I was using to sign commits on a private Guix > channel of mine. Is there a way to introduce a hard break in my channel > authentication? > > Despite updating authorization settings, pulls complain that my latest commit > isn't signed by an authorized key. > > Here are the changes I've made: > - New public key added to keyring branch > - Appended new key fingerprint to .guix-authorizations (at commit X) > - Update introduction in .config/guix/channels.scm > - Point to commit X > - Update openpgp-fingerprint > > As a sanity check, I've confirmed that the fingerprint on commit X, the > fingerprint in .guix-authorizations, and the openpgp-fingerprint in my > channels.scm are all the same. > > What am I missing? Hi all, from reading about guix authentication I think the new signing key must be first added to the .guix-authoriations file and that commit must signed with the current signing keys before the new signing key can be used. Best wishes, Markku
Losing signing keys for custom Guix channel
Hey devs, So I lost the PGP key that I was using to sign commits on a private Guix channel of mine. Is there a way to introduce a hard break in my channel authentication? Despite updating authorization settings, pulls complain that my latest commit isn't signed by an authorized key. Here are the changes I've made: - New public key added to keyring branch - Appended new key fingerprint to .guix-authorizations (at commit X) - Update introduction in .config/guix/channels.scm - Point to commit X - Update openpgp-fingerprint As a sanity check, I've confirmed that the fingerprint on commit X, the fingerprint in .guix-authorizations, and the openpgp-fingerprint in my channels.scm are all the same. What am I missing?
