From mboxrd@z Thu Jan 1 00:00:00 1970 From: ng0@n0.is Subject: Re: [RFC] A simple draft for channels Date: Wed, 24 Jan 2018 12:33:03 +0000 Message-ID: <87607rzbb4.fsf@abyayala.i-did-not-set--mail-host-address--so-tickle-me> References: <87bmhq6ytg.fsf@mdc-berlin.de> <87d1263qzt.fsf@gnu.org> <86fu6wh8aq.fsf@gmail.com> <87y3kocydw.fsf@abyayala.i-did-not-set--mail-host-address--so-tickle-me> <86po5zx12t.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:40373) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eeKEt-0001q2-Uc for guix-devel@gnu.org; Wed, 24 Jan 2018 07:33:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eeKEq-0007CO-Q2 for guix-devel@gnu.org; Wed, 24 Jan 2018 07:33:15 -0500 Received: from aibo.runbox.com ([91.220.196.211]:49552) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eeKEq-0007BT-Jd for guix-devel@gnu.org; Wed, 24 Jan 2018 07:33:12 -0500 Received: from [10.9.9.211] (helo=mailfront11.runbox.com) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1eeKEo-0003JE-3J for guix-devel@gnu.org; Wed, 24 Jan 2018 13:33:10 +0100 Received: from dslb-092-073-152-174.092.073.pools.vodafone-ip.de ([92.73.152.174] helo=localhost) by mailfront11.runbox.com with esmtpsa (uid:892961 ) (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) id 1eeKEi-0003AY-Ge for guix-devel@gnu.org; Wed, 24 Jan 2018 13:33:04 +0100 In-Reply-To: <86po5zx12t.fsf@gmail.com> (myglc2@gmail.com's message of "Wed, 24 Jan 2018 00:44:42 -0500") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: guix-devel@gnu.org myglc2@gmail.com: > On 01/23/2018 at 16:50 ng0@n0.is writes: > >> myglc2 writes: >>> On 01/19/2018 at 14:41 Ludovic Courtès writes: >>> >>>> Hi! >>>> >>>> Ricardo Wurmus 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/