myg...@gmail.com: > On 01/23/2018 at 16:50 n...@n0.is writes: > >> myglc2 writes: >>> On 01/19/2018 at 14:41 Ludovic Courtès writes: >>> >>>> Hi! >>>> >>>> Ricardo Wurmus <ricardo.wur...@mdc-berlin.de> skribis: >>>> >>>>> As a first implementation of channels I’d just like to have a channel >>>>> description file that records at least the following things: >> […] >>>> One thing that’s still an open question is how we should treat Guix >>>> itself in that channelized world. >>>> >>>> Should Guix be a “normal” channel? It’s tempting to think of it as a >>>> regular channel; however, it’s definitely “special” in that it can >>>> update the ‘guix’ command, maybe guix-daemon & co., locale data, etc. >>>> How does that affect ‘guix channel’? >>> >>> ISTM this design allows channels to inject non-free &/or non-safe >>> components into other user's Guix systems. Is that true? >>> >>> If so, how will it impact the Guix promise of software freedom/safety? >>> >>> WDYT? - George >> >> Just commenting on this one for now until I got my mail fixed: >> >> Why is this a problem? Already today you can run Guix with as many >> modifications as you like to, and you are free to install whatever you >> want. That's one of the very good aspects of Guix - you can use it to >> create whatever you like. Or maybe you need to expand a bit on the >> sentences you wrote George. > > Yes, and this is important to the current user base. But in the future > the majority of our users will be end-users that do not directly use FSF > freedoms & Guix hackability. Still, they will choose Guix because this > freedom and hackability provides indirect benefits such as enhanced > security and safety. > > Yes, FSF freedom means we must permit any user to shoot themselves in > the foot. But with GUIX_PACKAGE_PATH, this is not a worry. > > Channels dramatically increases the ease with which an end-user can harm > themselves by e.g. using a channel that delivers non-free &/or non-safe > software. This raises the question: are we obliged to, and if so, how do > we help end-users protect themselves from this risk?
In my honest opinion: No. We can not prevent this. All we can do is to provide a list of *official* channels. Beyond that I don't think we should try to regulate what's in an unofficial channel and what's allowed. It would be waste of time better spent in other parts of the project. -- ng0 :: https://ea.n0.is A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/
