Message ID | 20200625210400.29033-1-ludo@gnu.org |
---|---|
Headers | show |
Hi Ludo, On Thu, 25 Jun 2020 at 23:04, Ludovic Courtès <ludo@gnu.org> wrote: > The most visible effect is that channel introductions are now > part of the API and shown by ‘guix describe’. It becomes a long-term > commitment because we want to be able to pass the output of > ‘guix describe -C channels’ or /run/current-system/channels.scm > to ‘guix pull’ and ‘guix time-machine’ in the future. How could I test this machinery with "guix time-machine"? > Contrary to what I initially proposed¹, channel introductions are > stripped to the bare minimum: a commit/fingerprint pair (as is > currently the case on master, internally). I figured it doesn’t > buy us much to have the commit/fingerprint pair signed; what > matters is that users obtain the introduction from a trusted > source, and the signature wouldn’t help with that. I also got > rid of the idea of rendering introductions are opaque base64 blobs. What happens when traveling in time if the key used by the signature has been compromised? Today, everything is fine, I sign and I do in introduction. Couple of months (or even years) later, my key will be compromised and so I will revoke it. What happens if I do "guix time-machine -C"? Well, the question even applies to %default-channel? Maybe you already answered and I missed it. Cheers, simon
On Wed, 01 Jul 2020 at 14:17, Ludovic Courtès <ludo@gnu.org> wrote: > But of course, the new ‘introduction’ field of <channel> won’t be > recognized by older Guix versions. In that case, you should use the > output of ‘guix describe -f channels-sans-intro’ as I wrote in the > manual. Older Guix versions means the Scheme lib and not Inferiors, right? I mean, if I run using a Guix post-'introduction' "guix describe -f channels", then I can run with another Guix post-'introduction' "guix time-machine -C channels.scm", everything is fine. However, I cannot use this post-'introduction' channels.scm file with a pre-'introduction' Guix and "guix time-machine -C channels.scm" fails, right? > In general, when a developer loses control over their key, another > committer should remove it right away form ‘.guix-authorizations’. (I > did that today following Brett’s message, for example.) > > Signatures on past commits can still be verified and everything is fine. > The (guix openpgp) code ignores key expiration and revocation; it “just” > verifies signatures. > >> Today, everything is fine, I sign and I do in introduction. Couple of >> months (or even years) later, my key will be compromised and so I will >> revoke it. What happens if I do "guix time-machine -C"? > > That’s OK. The keyring is distributed along with the channel still > contains your key, with or without a revocation certificate, but that > doesn’t prevent us from verifying signatures on past commits. (This is > different from what gpg does.) It answers to my question about time-machine. Thank you. Now I have another one. :-) Well, if now Eve has the control of an authorized key (for example the Brett's one) then you cannot distinguish between past valid signatures to current malicious ones, even if the key is revoked, right? (It is not a practical issue but it is a possible scenario.) Cheers, simon
zimoun <zimon.toutoune@gmail.com> skribis: > On Wed, 01 Jul 2020 at 14:17, Ludovic Courtès <ludo@gnu.org> wrote: > >> But of course, the new ‘introduction’ field of <channel> won’t be >> recognized by older Guix versions. In that case, you should use the >> output of ‘guix describe -f channels-sans-intro’ as I wrote in the >> manual. > > Older Guix versions means the Scheme lib and not Inferiors, right? > > I mean, if I run using a Guix post-'introduction' "guix describe -f > channels", then I can run with another Guix post-'introduction' "guix > time-machine -C channels.scm", everything is fine. > > However, I cannot use this post-'introduction' channels.scm file with a > pre-'introduction' Guix and "guix time-machine -C channels.scm" fails, > right? Yup! > Well, if now Eve has the control of an authorized key (for example the > Brett's one) then you cannot distinguish between past valid signatures > to current malicious ones, even if the key is revoked, right? Revocation in the OpenPGP sense doesn’t not matter at all. What matters is whether the key is in ‘.guix-authorizations’. If we remove if from there in commit X, then any commit descending from X that is signed by that key will be rejected. Past commits (ancestors of X) signed by that key are still considered authentic. Ludo’.