bug#22883: Channel introductions

["Ludovic Courtès" <ludo@gnu.org>]

Hi,

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

> 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?

Nothing special, I guess: each channel would be authenticated (or not,
if it’s an unsigned channel).  I think it’s completely orthogonal.

>> >>   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.

I’m sorry, I don’t follow the terminology.

> 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.

Funny how “scientific” has become synonymous with “quick-and-dirty”
these days…

[…]

> 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.

Guix is a software supply tool.  There are two important security
questions a software supply client must address: “am I getting the
authentic stuff?”, and “am I getting the latest stuff?”.  The first one
is obvious, the second one relates to “downgrade attacks” which can
introduce known security vulnerabilities.

Things like The Update Framework (TUF) address both, but they do that in
a context that’s technically “like Debian” (binary distro) and very
different from Guix.

Yet, these two issues must also be addressed in Guix, like in any other
distro.

What we’ve been discussing here addresses the first question.  For the
second question, the best answer I came up with is that of an “official
URL”, allowing users to know the URL that should give them the latest
stuff.

“Official” means that it genuinely comes from the organization I
entrusted with my computer, be it the Guix project, another organization
maintaining a Guix fork, or an organization maintaining a Guix channel.

I hope that makes sense.

Thanks,
Ludo’.