forkkit/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 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.