Re: Update on distro bootstrapping with Guix

[Simon Josefsson]

address@hidden (Ludovic Courtès) writes:

> Simon Josefsson <address@hidden> skribis:
>
>> address@hidden (Ludovic Courtès) writes:
>>
>>> All in all, from experience with NixOS, while security upgrades are more
>>> demanding on Nix-based systems, they are not much of an issue in
>>> practice.
>>
>> Thanks for explaining.  However I don't see how a locally built binary
>> would fit into this?  They would either be insecure or not work after an
>> OS upgrade, wouldn't they?  Since they refer to libraries in paths that
>> no longer exists.  Or am I missing something?
>
> Nix & Guix are transparent source/binary deployment tools.  Suppose you
> have a Guix recipe to build a specific GnuTLS version, with a specific
> libtasn1, a specific GCC, etc.  If a pre-built binary that corresponds
> *exactly* to that recipe is available at the build farm, then it is
> downloaded; otherwise, the package gets built locally.  So whether it’s
> locally-built or not doesn’t matter.
>
> Perhaps you were asking about previously installed packages linked
> against a vulnerable libc, for example?  Again, those packages remain
> vulnerable, until you upgrade to the new version, that links against the
> fixed libc.
>
> (Similarly, in Debian, packages remain vulnerable until you run “apt-get
> upgrade”.)

I meant something I build locally as a non-root user on the system, a'la

wget http://ftp.gnu.org/...
tar xfa ...
cd ...
./configure && make

that will link to vulnerable libraries until it is rebuilt, wouldn't it?

That doesn't happen on a Debian/Ubuntu system, so it is a difference.

This could be solved by having a tree with symlinks to shared libraries
which stay the same across security updates.  E.g.,

/lib/libfoo.so -> 
/nix/store/r8vvq9kq18pz08v249h8my6r9vs7s0n3-libfoo-1.0/lib/libfoo.so

Has an (optional) symlink approach been considered, which would also
lead to more FHS compatibility?

>> Does guix have some mechanism to handle a set of installed packages and
>> their versions?  I'm thinking that you'd might want to lock down the
>> system to match a particular suite of tested software combinations, but
>> receive security upgrades for those packages, but not receive other
>> upgrades and certainly not receive the latest version of every package.
>> This would match how normal OS releases work.  The important thing is
>> that the set of installed packages should come from some server
>> somewhere, manually selected by the contributors to the project, and
>> that the list can be modified over time and updated automatically by
>> machines.
>
> With Guix & Nix, the distro is a set of package build recipes, including
> information to combine them together.
>
> Switching to a new glibc release in the distro consists in updating the
> build recipe of glibc.
>
> So, you can have several branches of the distro: “trunk”, which would
> correspond to “unstable” or “experimental” in Debian parlance, and
> “stable”, which would only get security updates.
>
> In fact, this is exactly how Nixpkgs has been managed over time: when a
> possibly destabilizing update is made (new major GCC or glibc version,
> new X library versions, new Qt version, etc.), a topic branch is made,
> which allows us to see its impact on all the packages of the distro, as
> it gets built on hydra.nixos.org.
>
> Most users obviously keep using “trunk”, which is the “stable” branch in
> Nixpkgs, and thus are not affected by the experimental upgrade going on
> in the other branch.

This sounds good.  Possibly you'd want to name the stable branches,
since over time you may have several of them maintained concurrently.
Compare how Ubuntu supports many stable releases at the same time.  For
some machines, I would not ever want software upgrades, but still be
interested in security upgrades.

>   • Guix is interoperable with Nix, so one can install Nixpkgs with Nix,
>     and they coexist with packages installed with Guix (right now,
>     Nixpkgs provides 10,250 source packages);

Ah, then it might be good enough for simple desktop use.

>> Personally, I'd be happy to use something based on Debian/Ubuntu but
>> profiled for GNU [1].  But I support all work that leads to more
>> technically interesting GNU-free OSes.
>
> Yeah.  I find support for parallel installations, complete dependency
> descriptions, per-user installations, atomic upgrades and rollback, and
> so on pretty compelling [0].  It’s a huge technical gap IMO.

Right, it is revolutionary, and there is some disadvantages with that
since it requires that everything adapt to the new model.  Minimizing
those costs will make it appear evolutionary and more people might
switch...

/Simon