Re: Scope of support for Guix on other distros

[Christopher Allan Webber]

Mark H Weaver writes:

> Hi Chris,

Hi Mark,

> Christopher Allan Webber <address@hidden> writes:
>
>> Mark H Weaver writes:
>>
>>> Tobias Platen <address@hidden> 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. <https://bugs.gnu.org/24703>.
>
> 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.

That's an interesting summary of things.  Okay, I'm convinced the "graft
our problem away" route won't work here.

> 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?

Hm.  I know I personally am wary of packages that are there just to be
installers for other packages (even though in effect if you do a guix
pull with a base package, you're kind of doing that anyway).  I'd
suspect we'll get more mileage at this point by just generating .deb
files and hosting them on our own site.

Thanks for the insightful comments!