Re: Scope of support for Guix on other distros

[Mark H Weaver]

Hi Chris,

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.

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