#22883 Trustable "guix pull"

Message #225 received at 22883@debbugs.gnu.org (full text, mbox, reply):

Received: (at 22883) by debbugs.gnu.org; 3 Jun 2020 16:20:51 +0000
From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 03 12:20:51 2020
Received: from localhost ([127.0.0.1]:44474 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces@debbugs.gnu.org>)
	id 1jgW8J-00044m-4W
	for submit@debbugs.gnu.org; Wed, 03 Jun 2020 12:20:51 -0400
Received: from mail-qk1-f172.google.com ([209.85.222.172]:36310)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <zimon.toutoune@gmail.com>) id 1jgW8H-00044Y-Eg
 for 22883@debbugs.gnu.org; Wed, 03 Jun 2020 12:20:49 -0400
Received: by mail-qk1-f172.google.com with SMTP id 205so2743855qkg.3
 for <22883@debbugs.gnu.org>; Wed, 03 Jun 2020 09:20:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=WM3O5jj0BGa3jFPLgT37vE9kOEmY9/YhC22vReuPhAk=;
 b=q8gfOtwbkCUYdZ6uAZLINivEqV7YzW8Sjd9bN2zOj//xHI9HwArUPIOPJsOHUXur6M
 sEVSMsZoGgUUOsa0JoYBq2RCyNfZa2qRLZjoyn7EXHjK13xDOxruecsF/TDdVBcpa9u4
 93QLX5KfTTNCH7b7w++dHzhDlUtVMyEy7AnpVcXrY68Ev2+Cz/SJ27YdA5IXubFViA4T
 Cdj6UpdLVhZiNitfYlFuDKgHmq03kuMpYwZigKuZYb3LxNiPwb8reweJMrwIWHKnaldV
 Iype4HhZthwb4cpT7XnoDn3JW30m/oEmfx+T2/v+CRV/PKy+uymiUjEiw6vFYcVuL8NA
 VesQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=WM3O5jj0BGa3jFPLgT37vE9kOEmY9/YhC22vReuPhAk=;
 b=enxezXj55gGQBSyeCmacwCtLAj5gyBr3elE1o87MYhS2eTiAaMMvydQGCKcpbTCz7S
 U3gQBfYwSmpwy3pWFQKjSr5KDphf9DXlOvwRU+kxGVB4K7KjXwXQ//uYb67L8Ed+Q94C
 M3A5VgnVvPyaYjy9Ho9QEA5SBP5Aifxn0TvwpVBBJGPzLLvOwd5tRwamNwaTEAZGhGT/
 Zj6fBtCRy4pHQfWyXc04elDydFdkRpoOixBhohQ0nWRx93JUUzPfPrQbCLCAYd4SOAOY
 KVP40HjWQNjkiSI5gvXDaioZIxbc8i8k+KkRJdZvgTAK9TGMTflokgBYIuOEV1qw0+6N
 6WjQ==
X-Gm-Message-State: AOAM530qWzrRNAZ8iAKx3M5P8HotqY1brBAz+2ONgn3skXryty2r4ZFC
 jn30M+AOnfIjMVLJE5Ic40s6sQPaVfyKrXbgA/A=
X-Google-Smtp-Source: ABdhPJzD3r9KiRE08Sb7HB7+BwQ1PGFKzmIftXBKUnD+9WULXHd1ViMC+Ffq3fMj3EsX+NvmmF7ht/f/fNwRZXg1aHQ=
X-Received: by 2002:a37:4b88:: with SMTP id y130mr462303qka.80.1591201243806; 
 Wed, 03 Jun 2020 09:20:43 -0700 (PDT)
MIME-Version: 1.0
References: <87io14sqoa.fsf@dustycloud.org> <87h9ep8gxk.fsf@gnu.org>
 <20160426001359.GA23088@jasmine> <874majg0z8.fsf@gnu.org>
 <87bn3iz1xc.fsf_-_@gnu.org>
 <87wpket748.fsf@gnu.org> <87bmkwm8ed.fsf@gnu.org> <87png9o8i2.fsf@elephly.net>
 <87fth4bj6y.fsf@gnu.org> <87bln9oupo.fsf@gnu.org> <87wo5vfuxi.fsf@gnu.org>
 <87o8qjekt7.fsf@gnu.org> <87v9kanalz.fsf_-_@gnu.org>
 <CAJ3okZ197ip5HG8P66tVhtNiTcxBv63yfWk7LMeYy=A-Vx2d-Q@mail.gmail.com>
 <875zc8pjfu.fsf@gnu.org>
In-Reply-To: <875zc8pjfu.fsf@gnu.org>
From: zimoun <zimon.toutoune@gmail.com>
Date: Wed, 3 Jun 2020 18:20:32 +0200
Message-ID: <CAJ3okZ2DXeh-FzCj5t_+aVmfe9jsyN6araq0nnPOq_ZMbpp5TA@mail.gmail.com>
Subject: Re: bug#22883: Channel introductions
To: Ludovic Courtès <ludo@gnu.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 22883
Cc: 22883@debbugs.gnu.org
X-BeenThere: debbugs-submit@debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request@debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit@debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request@debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request@debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces@debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

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

Send a report that this bug log contains spam.