bug#22883: Channel introductions

[zimoun <zimon.toutoune@gmail.com>]

Hi Ludo,

Thank you for the explanations.

On Wed, 3 Jun 2020 at 11:50, Ludovic Courtès <ludo@gnu.org> wrote:
> zimoun <zimon.toutoune@gmail.com> skribis:
> > On Mon, 1 Jun 2020 at 16:08, Ludovic Courtès <ludo@gnu.org> wrote:

> >>      If that information were stored in ‘.guix-channel’, it would be
> >>      trivial for an attacker to fork the project (or push a new commit)
> >>      and pretend the authentication process must not take previous
> >>      commits into account.
> >
> > What will happen to recursive '.guix-channel'?  The '.guix-channel' of
> > channel A contains the reference to the channel B where the
> > '.guix-channel' contains the reference to the channel C, etc.
>
> I’m not sure I understand.  (The sentence above is about *not* storing
> info in ‘.guix-channel’.)

Sorry, I have misread.
The question about recursive still applies. ;-)
Currently, if the local channel file points to a channel A which
contains the file '.guix-channel' which points to another channel B,
then when one runs "guix pull" well the channel A will be pulled and
then the channel B, even if this channel B is not explicit in the
initial local channel.  (Even, there is bug about recursive implicit
pulls, see http://issues.guix.gnu.org/issue/41069; well another
story.)

What happens for such situation?


> >> I think we need a way to “introduce” a channel to its users that goes
> >> beyond a mere URL.
> >
> > Just to be sure to well understand, will the good ol'
> > ~/.config/guix/channels.scm
> >
> >      ;; Tell 'guix pull' to use my own repo.
> >      (list (channel
> >              (name 'guix)
> >              (url "https://example.org/my-guix.git")
> >              (branch "super-hacks")))
> >
> > still work as it is now? i.e., using the current "unauthorized"
> > mechanism.  Or will a new keyword be added to this channel description
> > to say "this channel does not use authorized machinery but it is
> > fine"?
>
> Yeah, we have to keep it working.  So I guess in that case it would just
> emit a warning saying this channel is not authenticated, and that’s it.

[...]

> >>   4. When publishing a fork of a channel, one emits a new channel
> >>      introduction.  Users switching to the fork have to explicitly allow
> >>      that new channel via its introduction; flipping the URL won’t be
> >>      enough because ‘guix pull’ would report unauthorized commits.
> >
> > I am a bit afraid by this... and I hope that a fork of a channel will
> > still work without emitting a new channel introduction.
>
> No, when publishing a fork of an authenticated channel, you’ll have to
> publish its introduction alongside its URL.

I do not understand your two answers.  Well, there is 4 situations
when publishing:

 1- an authenticated fork of an authenticated channel
 2- an authenticated fork of an unauthenticated channel
 3- an unauthenticated fork of an authenticated channel
 4- an unauthenticated fork of an unauthenticated channel

"authenticated channel" means a channel using all the authentication machinery.
"authenticated fork" means add a "channel introduction" and so become
a "authenticate channel" then.

Today, we are in the situation 4. and we are going to the 1.  if I
understand correctly.
And if I understand your answer above about good ol' channel, the 4.
will still work and emit a warning, isn't it?
What about the 2. and 3.?

These situations correspond to:

1- the correct way
2- bootstrap the trust
3- and 4- quick and dirty "Scientific" workflows where the security is
not a concern.


> I think it’s unavoidable: we want to be able to distinguish between a
> mirror that has been tampered with and a fork.

I understand.  But this break the symmetry and the distributed model
of Guix, IMHO.


> >>   5. The channel URL is not included in the introduction.  However, the
> >>      official URL is an important piece of information: it tells users
> >>      this is where they’ll get the latest updates.  It should be
> >>      possible to create mirrors, but by default users should go to the
> >>      official URL.  They should be aware that mirrors can be outdated.
> >
> > I do not understand this paragraph.  The aim of mirrors is to avoid
> > the users to go to the official URL, isn't it?  And the mirrors do not
> > have by design the latest updates (time to propagate, etc.).
> >
> >>      I think the official URL can be stored in ‘.guix-channel’ in the
> >>      repo (which is subject to the authentication machinery).  That way,
> >>      ‘guix pull’ can let the user know if they’re talking to a mirror
> >>      rather than to the official channel.
> >
> > Why does it matter?  The user should authenticate the downloaded
> > content whatever the URL serving it, isn't it?
> > And can 'guix pull' already let the users know to who they are talking?
>
> You’re right: ideally the URL wouldn’t matter at all.  However, from a
> security perspective, we not only want to make sure users get genuine
> commits, we also want to know they’re not talking to a possibly outdated
> mirror.

Genuine commits and outdated mirrors are separated questions, IMHO.


> Since there’s no way to answer the question “is this the latest commit?”
> in a general way, the best we can do, I think, is to detect whether
> we’re talking to the “official” Git repo.

What does "official" mean here?  To me, it means commits that I trust,
i.e., approved by an authority.  My local clone is not less "official"
than the repo on Savannah.

I do not understand why the question “is this the latest commit?” has
to be answered.  If an user wants the latest commits, then they
directly pulls from upstream, i.e, from Savannah.  If an user wants to
pull from a mirror for whatever reasons, then they knows that the last
updates are not necessary there, since it is a mirror and not upstream
-- and it is the responsibility of the mirror maintainer to keep it
up-to-date.  However, what the user wants to know is whether the
mirror has not introduced malicious commits.


Thank you for all that.
Cheers,
simon