Hi, On Tue, 30 Jun 2020 at 22:28, Ludovic Courtès wrote: >> One thing that I worry about is authentication of channels that are >> added as dependencies of user-selected channels. Let’s say my channel >> “guix-bimsb” depends on “guix-past”. How will users of “guix-bimsb” >> authenticate the commits of “guix-past” when they don’t know about >> “guix-past” (they only care about “guix-bimsb”), and don’t explicitly >> add introduction information to their channels file? >> >> Is there something that the authors of “guix-bimsb” can do to not only >> indicate the dependency on “guix-past”, but also to attach introduction >> information? Will the format of the “.guix-channel” need to be >> adjusted? > > That’s a very good question and I had completely overlooked it. Héhé, yet I had the same question one month ago. :-) --8<---------------cut here---------------start------------->8--- > 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. --8<---------------cut here---------------end--------------->8--- http://issues.guix.gnu.org/issue/22883#75 > With this patch set, someone pulling guix-bimsb would just end up > pulling guix-past unauthenticated; there’s not even a warning. > > (There’s currently a warning in (guix channels), but only when pulling > an unauthenticated 'guix channel. It’s perhaps too early to have that > warning enabled for all channels. WDYT?) Enable the warning appears to me a good idea because this dependency is like "doing something I am not necessary aware in my back". For example, the first time I pulled the channel "guix-bimsb-non-free" which depends on "guix-bimsb", it took me some time to understand why "guix-bimsb" was pulled twice and once with a name I do not have in my local channels.scm file. Anyway. > So yes, I suppose we would need to extend the ‘.guix-channel’ format for > dependencies. Luckily it should be quite simply because that format is > extensible; older Guix versions would ignore the ‘introduction’ field. > It would look something like this: > > (channel > (version 0) > (dependencies > (channel > (name some-collection) > (url "https://example.org/first-collection.git") > (introduction (channel-introduction > (version 0) > (commit "…") > (signer "…")))) > (channel > (name some-other-collection) > (url "https://example.org/second-collection.git") > (branch "testing")))) ;not an authenticated channel > > It does mean that a channel can indirectly trick you into turning off > authentication for a dependent channel. But I think that’s within the > expectations for channels: when you choose a channel, you trust it > enough to run its code. Sound good to me. When I choose a channel, I trust the people enough to run their code. But I do not trust the URL which serves it. I mean, it is the point of all this new authentication mechanism, isn't it? However, I agree. Channel should stay easy to fork and add something (then maybe send a pull-request) without going in all the GPG signature dance and/or running the options --allow-downgrades or --disable-authentication (I do not remember the exact name). Cheers, simon