[Nix-dev] Proposal: Highly available security-specific trusted build infrastructure

[Shea Levy]

The existing infrastructure will always have more load and be more
complex than what is needed for security updates. hydra is a fully
general CI system, and properly so, but it means the system is subject
to bugs and constraints that a simpler more focused system can avoid.

Moreover, for better or for worse hydra.nixos.org is only manageable by
a small set of people who are not always available to service it (nor
should they have to be!). No amount of improving hydra will fix that.

~Shea

Graham Christensen <graham at grahamc.com> writes:

>  -1 I think a better approach would be to bolster and support the existing
> infrastructure and fix its issues, not create a whole new set. Hydra
> already spins up and down AWS nodes depending on the number of jobs.
>
>  - https://github.com/NixOS/hydra-provisioner
>  -
> https://github.com/NixOS/nixos-org-configurations/tree/master/hydra-provisioner
>  - https://hydra.nixos.org/machines -- I believe if you whois the
> struck-out IPs they'll all belong to AWS
>
> On Sun, Oct 16, 2016 at 12:56 PM Shea Levy <shea at shealevy.com> wrote:
>
>> Hi all,
>>
>> hydra.nixos.org is a wonderful community resource, but its broad scope
>> and somewhat frequent downtime concerns me when it comes to security
>> updates. As a supplemental service, I propose we have a service, hosted
>> by a professional hosting company with 24/7 support and with multiple
>> trusted community members having administrative access, dedicated to
>> building only critical security updates and uploading them to the binary
>> cache, with the intention that these be used with
>> system.replaceRuntimeDependencies/pkgs.replaceDependency until hydra has
>> had a chance to update the entire channel. This service could work via
>> manual triggering by trusted users, github push notifications and commit
>> message parsing (to get the relevant attributes to build), signed git
>> commits, or some combination of these, and would *only* build the
>> directly affected packages (e.g. only rebuild glibc for a glibc
>> vulnerability, expecting users to use replaceDependency until hydra is
>> caught up). If it turns out to be useful, it could spin up AWS build
>> machines on demand to ensure a very rapid turnaround.
>>
>> Thoughts on this? I'm happy to help fund this significantly, but it
>> loses a lot of its value if it doesn't directly upload to the nixos.org
>> cache so I think it needs official support before following through.
>>
>> Thanks,
>> Shea
>> _______________________________________________
>> nix-dev mailing list
>> nix-dev at lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.science.uu.nl/pipermail/nix-dev/attachments/20161016/a97305de/attachment-0001.sig>