[Nix-dev] nix proposal for security fixes
roconnor at theorem.ca
roconnor at theorem.ca
Sun Sep 28 23:58:03 CEST 2014
We already have shlevy's "replaceDependency" which, IMHO, solves this
problem.
In functional programming when we have an immutable tree structure that we
want to update, we trace a path from the root of the tree to the node that
we want to update and we update all the nodes along that path to point to
a newly created "spine" and we get a new tree that shares all unchanged
subtrees with with the old tree.
shlevy's replaceDependency, and his related NixOS module
system.replaceRuntimeDependencies, works in the same way. Starting from
the root derivation, typically your NixOS system, but could be your
user-enviroment, we can traverse the entire tree of runtime dependencies
and replace one package, say bash, with another package. Then we replace
all the nodes between those adjusted subpackages and the root package with
new nodes that are identical to the old nodes except they have their
references updated to point to the new nodes. These new nodes are created
by derivations that use the old node binaries as "source files" and run
sed to replace the /nix/store/references.
The result is a new NixOS sytem/user-environment that references the
replacement package everywhere and this all done in a purely functional
manner.
While this process isn't quite as fast as our mutable cousin's procedure
of updating packages in place in a matter of seconds, this
replaceDependency tree update process can be done in a few minutes without
any extenstions to Nix. For me, I think building bash took more time than
replaceDependecy process and it is certainly faster than the hours or days
it will take to rebuild the whole system.
On Sun, 28 Sep 2014, Lluís Batlle i Rossell wrote:
> Hello!
>
> It could be nice if we had a nix derivation attribute that allowed the
> determination of a store path, overriding the hash mechanisms for it.
>
> Imagine that we have a bash to fix; we could add a line in the bash derivation
> attribute set:
> forceOut = "whatever store path out"
>
> It'd be nice if nix tools allowed to list (or mark specially on screen)
> derivations that have forceOut paths. It should be applied only in case of
> security fixes.
>
> An operation like "nix-store --repair" should, then, allow for a global system
> update.
>
> Another approach, non intrusive to nixpkgs, would be to allow nix to read such a
> list of hash overrides (hash → desiredHash) from nix.conf or so. It'd allow for
> anyone who cares to get some protection without waiting hydra.
>
> Of course this makes sense for elf programs or shared objects, and not for
> static libs. And hydra should not be using this trick. :)
>
> What do you think? Maybe all this even exists already. :)
>
> Regards,
> Lluís.
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
--
Russell O'Connor <http://r6.ca/>
``All talk about `theft,''' the general counsel of the American Graphophone
Company wrote, ``is the merest claptrap, for there exists no property in
ideas musical, literary or artistic, except as defined by statute.''
More information about the nix-dev
mailing list