mbox

[bug#42048,0/6] Authenticated channels for everyone!

Message ID 20200625210400.29033-1-ludo@gnu.org
Headers show

Message

Ludovic Courtès June 25, 2020, 9:04 p.m. UTC
Hello Guix!

This patch series follows up on channel authentication support:

  https://issues.guix.gnu.org/41767

This time the goal is to expose and document the authentication
mechanism so that third-party channel authors can use it.  This
should be the last series on this theme in the foreseeable
future.  :-)

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.

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.

In the manual I tried to distinguish instructions for users
(“what do I need to put in my channels.scm file?”) from
instructions for channel authors (“how do I allow users of my
channel to authenticate it?”).

If people have a channel that they’d like to make “authenticable”,
please do try and report back!  You can even test with master,
you only need to add ‘@@’ to access (guix channels) internals
to create the introduction.

Feedback welcome!

Thanks,
Ludo’.

¹ https://issues.guix.gnu.org/issue/22883#69



Ludovic Courtès (6):
  channels: Add 'openpgp-fingerprint->bytevector'.
  channels: Make channel introductions public.
  channels: Remove 'signature' from <channel-introduction>.
  channels: Save and interpret 'introduction' field in provenance data.
  guix describe: Display channel introductions and add
    'channels-sans-intro'.
  services: provenance: Save channel introductions.

 doc/guix.texi             | 130 +++++++++++++++++++++++++++++++++++++-
 gnu/services.scm          |  26 ++++++--
 guix/channels.scm         |  86 +++++++++++++++++++------
 guix/scripts/describe.scm |  56 +++++++++++++---
 guix/scripts/system.scm   |   4 +-
 tests/channels.scm        |  10 ++-
 6 files changed, 269 insertions(+), 43 deletions(-)

Comments

Simon Tournier July 1, 2020, 9:35 a.m. UTC | #1
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
Simon Tournier July 1, 2020, 1:09 p.m. UTC | #2
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
Ludovic Courtès July 1, 2020, 3:54 p.m. UTC | #3
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’.