bug#22883: Channel introductions

[Ludovic Courtès]

Hi,

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

> On Mon, 1 Jun 2020 at 16:08, Ludovic Courtès <ludo@gnu.org> wrote:
>
>> 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.

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

>>   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 think it’s unavoidable: we want to be able to distinguish between a
mirror that has been tampered with and a fork.

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

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.

Thanks for your feedback!

Ludo’.