[Nix-dev] nix proposal for security fixes

[Lluís Batlle i Rossell]

ahhh I never used it. I will! Thank you.
On Sun, Sep 28, 2014 at 08:11:30PM -0400, Shea Levy wrote:
> 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
>