trustix

* Trustix - A new model for Nix binary substitutions

** Problem description
The Nix binary substituters are a single source of failure in the chain of trust when delivering binaries to Nix users.
This is problematic for several reasons:

- Getting code execution on the [[https://hydra.nixos.org/][NixOS Hydra]] build machines means it's possible to upload backdoored builds.
And the way https://cache.nixos.org is set up does not make key-rolling easy.
This means that a key compromise would realistically mean that _all_ packages would have to be rebuilt or garbage collected.

- The NixOS Hydra _hardware_ may not be considered trustworthy by some more security conscious users.

** Trustix design
=Trustix= aims to solve this problem by allowing distributed trust & trust agility.

This is achieved through the following methodology:
*** Each builder is associated with public-private key pair
*** In a post-build hook the output hash (NAR hash) of the build is uploaded to a ledger

This allows a user to:
- Trust binary substitutions on an M-of-N basis
Let's say we have 4 builders configured: =Alice=, =Bob=, =Chuck= & =Dan=.
We have configured =Trustix= to require a 3/4 majority for a build to be trusted.

=Alice=, =Bob=, & =Dan= have all built the =hello= derivation but =Chuck= has not
All 3 builders have arrived at the same output hash.

This build can now be considered trusted and we can use the binary substitution.

- Automatically identify misbehaving builders
Let's say again that we have 4 builders configured: =Alice=, =Bob=, =Chuck= & =Dan=.

=Alice=, =Bob=, =Chuck= & =Dan= have all built the =hello= derivation but has not arrived at the same output hash!
We can now identify that =Chuck= is up to no good and may decide to distrust this builder from future substutions completely.

- Track build reproducability across a large number of builders
As a nice side-effect of the systems general design we can now track reproducability across all builders participating in the global namespace.