[bug#41767] [PATCH 0/9] Authenticate channels

[Ludovic Courtès]

Hi Simon,

zimoun <zimon.toutoune@gmail.com> skribis:

> From my understanding, there are 4 situations
>
>  1- add signed material to a signed channel
>  2- introduce authentication to an unsigned channel
>  3- add unsigned material to a signed channel
>  4- add unsigned material to unsigned channel

I’m not sure what material you have in mind.

There are in my view only two situations: a channel that can be
authenticated (it has signed commits, ‘.guix-authorizations’, and an
“introduction”), and one that cannot.

The idea is that a channel that can be authenticated would remain that
way “forever”.

> And I am interested by how it works for the situation #3.  For a
> concrete example of 3., e.g.,
>
> git clone https://git.savannah.gnu.org/git/guix.git
> git worktree add -b foo wk/foo
> cd wk/foo
> # add my unready stuff
> ./pre-inst-env guix pull --branch=foo --url=$PWS -p /tmp/foo
> /tmp/foo/bin/guix install unready-stuff
>
> In this case, do I have to use the option '--disable-authentication'?

Yes, you can always use it.

> And this is the scenario for almost all the patches on guix-patches;
> even if 'pull' is generally not necessary when testing the patch. :-)

Right.  When hacking, I just use ./pre-inst-env to test my stuff.

> Another example is let consider that this channel [2] -- or any other
> public one used by labs to publish specific tools; I am not aware
> about one by INRIA ;-) -- and let imagine that this channel is
> authenticated, i.e., there is a '.guix-authorizations' file.  Now, can
> I fork this channel and my unsigned material without entering in the
> security dance?  Do I need to use the option
> '--disable-authentication'?

Note that this patch set changes nothing for third-party channels.
(Attentive readers will find out how to make an authenticated channel,
but it’s undocumented and inconvenient to use.)

In the future, I think ‘guix pull’ will merely print a warning when
using an unauthenticated channel.  That’s something we’ll have to
discuss.

If you want to fork an “authenticated channel”, you don’t have to keep
it authenticated.  In essence, something who writes:

  (channel (name 'zimoun) (url "https://zimoun.example.org";))

states that they want to fetch code from your channel, but that no
authentication will take place because there’s no ‘introduction’ field.

> Moreover, if this forked channel is added to
> '~/.config/guix/channels.scm', i.e., in addition to
> '%default-channel', what happens for pulling?  Well, it is not
> possible to pull a signed channel and an "unauthorized fork from a
> signed channel" in only one command, right?

With this patch set, ‘guix pull’ just behaves the same as now.
In the future, it would probably just print a warning about the
unauthenticated channel.

> Well, I am sorry to be insistent but this authentication machinery
> seems having an hard implication in my workflow and I would like to be
> prepared.

Definitely, feedback like this is very helpful.

I think it’s important for all of us to think about the implications.
Surely we want security, but not at the cost of usability.

Thanks,
Ludo’.