Hi, zimoun skribis: > On Mon, 1 Jun 2020 at 16:08, Ludovic Courtès 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’.