[Nix-dev] nix proposal for security fixes

[Shea Levy]

Yes, this is exactly what replaceDependency is for.

On Sun, Sep 28, 2014 at 02:58:03PM -0700, roconnor at theorem.ca wrote:
> 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.''

> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev