It sounds like a necessary evil. Another option would be to make Hydra super fast... What has been explored to optimize compile speeds? Using distcc, ccache, SSD, elastic scaling?
What if we had a security build fund that we could use to briefly run 500 machines to complete security builds? Would that allow 2-hour security rollouts? Wout. On Thu, Sep 25, 2014 at 10:19 AM, Luca Bruno <lethalma...@gmail.com> wrote: > My proposal is to have an hydra security channel independent of nixpkgs. > > SAMPLE USAGE > > nix-channel --add > http://hydra.nixos.org/jobset/nixos/security/channel/latest > > The channel will provide a <nixos-sec/module.nix> to be imported by the > users in their configuration.nix. > > The nixos-sec/module.nix will add the relevant security updates[1]. > > WRITING SECURITY UPDATES > > It must be ensured that the fixed software has the same ABI/API of the > one getting replaced, so that the security updates can work > independently of nixpkgs/nixos channel updates. > > To achieve this, the derivation version should be parsed and checked > against the new version. > Also if the version of the software being replaced is higher than fixed > version, then the replace must not happen. > A couple of utility functions should suffice in writing such security > updates. > > In general, I think it's better to use overrideDerivation + src + > patches, so that if the user ever customized compilation flags or > anything else, the security update will be as least invasive as possible. > > Best regards, > > [1] https://nixos.org/wiki/Security_Updates > > _______________________________________________ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev >
_______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev