From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: Scope of support for Guix on other distros Date: Tue, 03 Oct 2017 15:16:36 -0400 Message-ID: <87r2uk9h4b.fsf@netris.org> References: <1506935892.5574.15.camel@gmail.com> <9f2ed1cd-f7df-1a8f-8789-15bc53e46233@fastmail.net> <87tvzh5ylu.fsf@dustycloud.org> <20171002163817.bypveuihimo5akw2@abyayala> <87shf15qn0.fsf@dustycloud.org> <5583a861-8720-d03f-a56b-240d88bf04ea@platen-software.de> <87h8vgegdr.fsf@netris.org> <87fub03499.fsf@dustycloud.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:38232) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzSgh-0005EI-89 for guix-devel@gnu.org; Tue, 03 Oct 2017 15:17:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dzSge-0000pt-2V for guix-devel@gnu.org; Tue, 03 Oct 2017 15:17:03 -0400 Received: from world.peace.net ([50.252.239.5]:55826) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dzSgd-0000on-Te for guix-devel@gnu.org; Tue, 03 Oct 2017 15:16:59 -0400 In-Reply-To: <87fub03499.fsf@dustycloud.org> (Christopher Allan Webber's message of "Tue, 03 Oct 2017 05:38: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: Christopher Allan Webber Cc: guix-devel@gnu.org Hi Chris, Christopher Allan Webber writes: > Mark H Weaver writes: > >> Tobias Platen writes: >> >>> On 02.10.2017 20:52, Christopher Allan Webber wrote: >>>> Since these don't provide Guix in the main repo (and Debian won't >>>> because we violate the FHS with /gnu/) we could probably auto-generate >>>> the .deb or .rpm from some gexp? >>>> >>> Debian also includes GNUstep which lives in /usr/gnustep. Maybe /gnu >>> could be moves to /usr/gnu on Debian. >> >> All of our binary substitutes are built with a store prefix of /gnu. >> Using a different store prefix requires bootstrapping the entire system >> from source code, once per core-updates cycle, and also doing frequent >> rebuilds of upper layers of the stack to keep up with the updates on our >> master branch. Most users won't want to do this. > > I still think a hilarious option would be to "graft" every output to > /usr/gnu or /opt/gnu but I think nobody else is on board with this ;) I've had similar thoughts in the past, but upon further reflection, it would raise serious technical difficulties. So far, grafting only attempts to change individual components of file names (i.e. between two '/'s), which is prudent because it's entirely possible that some software stores the components separately, or uses a different directory separator internally. I don't know how much of a problem this would be in practice, but stranger things have happened, e.g. . If we neglect that issue, the next problem is that grafting obviously cannot change the length of file names embedded within executables and data files of arbitrary format, so in order to add 4 characters to the beginning of file names, we'd have to discard 4 characters from somewhere else. Discarding 4 characters from the hash would seem to be the obvious choice, but that would entail making it about a million times easier to generate a hash collision. If someone can successfully cause a hash collision, that could be used to breach the security of the system. There's also the fact that quite a bit of code in Guix assumes a fixed hash length, and it would take some effort to lift that limitation. The safer approach would be to discard 4 characters from the human-readable part of the file names (i.e. the package name and/or version number), which would obviously hinder readability. This would be a lot of fuss for very little benefit, in my opinion. The sole benefit would be to allow Debian users to install a (very old) version of Guix from Debian's own repository instead of having to use our own (up-to-date) .deb file. As a long-time Debian user myself, I can very much sympathize with the desire to avoid using outside repositories. My main reason for this is that on a Debian system, I've already put full trust in the Debian developers and infrastructure, and I'd rather avoid trusting anyone else if I can avoid it. However, that reason is not applicable here, because it's not possible to use Guix without putting tremendous trust in the Guix developers, regardless of where the original .deb came from. If we were to try to add a package to Debian, it might be better to add a package that downloads, authenticates, and installs our latest binary installer. Most importantly, this would allow us to leverage Debian's existing infrastructure to securely distribute a copy of our signing key to new users, and allow slightly more convenient install without condemning users to starting with an ancient version of Guix. What do you think? Mark