[Nix-dev] Improving security updates

Nicolas Pierron nicolas.b.pierron at gmail.com
Fri Apr 10 23:16:54 CEST 2015


Hi,

On Fri, Apr 10, 2015 at 7:12 PM, CodeHero <codehero at nerdpol.ch> wrote:
> So, after this huge update delay for nixos-unstable I think we should
> talk about improving the way security updates are handled. One can
> currently install security upgrades by using the instructions on this
> page (https://nixos.org/wiki/Security_Updates), but it's a lot of work
> to find all the libs that need those updates; and flagging packages as
> security updates will most likely not work without a dedicated security
> team.
>
> We've been brainstorming a little bit on the irc
> (https://botbot.me/freenode/nixos/2015-04-10/?msg=36316600&page=4), and
> we came up with a few ideas. I personally like the extra security branch
> idea, but i'm not sure how it would work out
> (https://botbot.me/freenode/nixos/2015-04-10/?msg=36318539&page=5), so
> that's why I'm asking here. Maybe somebody has some ideas and the
> know-how to make things better.
>
> The question is: who has suggestions on how to improve the installation
> of critical security updates; who knows how to implement the best
> suggestion; and who will maintain it?

I want to enumerate a few points that we should keep in mind:
 1. This should be done as part of nixpkgs, and not as part of nixos
 2. This should be transparent for the end user.
 3. We should provide tools to watch for security updates. (polling /
push-notifications)

Currently the only way to provide fast security updates is to
substitute in-place the packages which are vulnerable.  I do not think
that we have better alternative here.
Still, I think there is a problem with the approach suggested on the
wiki (https://nixos.org/wiki/Security_Updates  ), which is that there
is no automatic relation between the original package and the fix.

The problem I can see with `replaceDependency`, is that we replace
`hash-vul` by `hash-fix` in one derivation, but not in all derivations
which are depending on `hash-vul`.
This leads to 2 questions:
 - How do we know that `hash-vul` is vulnerable ?
 - How do we know that one derivation depends on `hash-fix` ?

Nixpkgs does not know about anything about runtime dependecies (except
for cross-compilation), it only know things about build dependencies.
This implies that one package can depend on a dependency of its
dependencies.  Thus we have to carry over the hash substitution of the
dependencies.

A: buildInputs = [ B ];
B: buildInputs = [ C ];
C: [ { vul = ; fix = ; } ]

A: [ /* A */ { vul = ; fix = ; } /* B */ { vul = ; fix = ; } /* C */ {
vul = ; fix = ; } ]
B: [ /* B */ { vul = ; fix = ; } /* C */ { vul = ; fix = ; } ]
C: [ /* C */ { vul = ; fix = ; } ]

So basically, we want a channel, which is constructed by merging the
`last`, with the `small`.  Basically, the merge will flag all `small`
(fix) packages as being a replacement of the `last` (vulnerable).
Then we replace the `stdenv.mkDerivation` function to do the
substitution if the original derivation depends on a fixed small
package.

This method implies that we should never bump the version of small
packages across ABI-incompatible changes.  Which means that we would
have to ensure that any small package is versioned in nixpkgs, at
least until the next `last` channel update.

At the end, the small channel should mirror the latest channel, with
delta binary patches for all fixes of the small packages.

I think this is all :)

-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/


More information about the nix-dev mailing list