[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#22883: Channel introductions
bug#22883: Channel introductions
Wed, 03 Jun 2020 11:50:13 +0200
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)
zimoun <email@example.com> skribis:
> On Mon, 1 Jun 2020 at 16:08, Ludovic Courtès <firstname.lastname@example.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'
> ;; 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
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
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!