[Nix-dev] Using Nix for deterministic and verifiable builds

Gregory Szorc gregory.szorc at gmail.com
Sun Nov 16 23:09:51 CET 2014


I discovered Nix and NixOS a few weeks ago and love what I see. I love 
the execution of immutable and standalone environments. IMO Nix is 
packaging done right. There is so much potential for Nix and NixOS on so 
many fronts.

One of the potential applications I'm investigating Nix for is 
deterministic and verifiable builds. I work at Mozilla, where I'm a 
maintainer of the Firefox build system. We (Mozilla) have a goal for 
anyone in the world to be able to produce a bit-identical copy of 
Firefox that matches the official binaries Mozilla releases. That is 
deterministic builds. We also want to enable verifiable and trusted 
builds. It's not enough for Mozilla to supply you an archive of the 
build environment [that could potentially be compromised]: we want to 
enable you to reproduce that build environment from scratch. (Read more 
about these trust issues at [1] and [2].)

The Tor Project has already accomplished this using Gitian [3] to manage 
the build environment [4][5]. I mean no disrespect for Tor or the Gitian 
people, but Nix seems like a better tool for the job. Gitian just 
doesn't feel as robust to me. Yes, it gets the job done. But I view Nix 
as the end state of "Gitian done right."

I'm curious about what people in the Nix community feel about the 
applicability of Nix to the deterministic and verifiable builds problem 
space.

 From my limited experience with Nix, I *think* the determinism part is 
on solid ground: if you assemble the same environment on different 
machines and a package is capable of building deterministically, you're 
in a good position to achieve a bit-identical result. (We really only 
care that Firefox's output is deterministic - it doesn't matter too much 
if the toolchain and dependent packages aren't deterministic as long as 
Firefox builds the same. Although, having bit-identical output 
everywhere would be awesome.)

What I'm not certain on is how Nix solves the verification and trust 
issues. I know source archives and other files can be verified after 
download, etc. That's great. What isn't clear to me is how Nix handles 
the "determinism over time" + trust problem.

I *think* you can facilitate determinism over time by providing your own 
channel or version control repository of Nix expressions. Then, you tell 
people "checkout version X and install the 'firefox-build-env' package." 
You attain trust via regular auditing of the Nix expressions. Is it 
really this simple? How do you achieve full isolation of a Nix 
expressions "database" from other installed channels/sources? Is having 
a version controlled repository of Nix expressions that can be used to 
derive the same (hopefully identical) packages over time something that 
people do? e.g. if I check out a copy of the Nix expressions from a year 
ago and realize the "firefox-build-env" package, I should compile the 
environment as it was a year ago, right?

Please forgive me for not having complete Nix understanding yet. I think 
I have enough comprehension to see that Nix could work for Mozilla's 
needs here. I just don't know if Nix is really the best tool for the job 
or what the end state would look like with Nix. I'm really curious what 
others have encountered dabbling in this problem space.

Thanks in advance,

Gregory

indygreg on Freenode
gps on irc.mozilla.org

[1] https://www.schneier.com/blog/archives/2006/01/countering_trus.html
[2] 
https://people.torproject.org/~mikeperry/transient/2014MozillaReproducible.pdf
[3] http://gitian.org/
[4] 
https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and-global-compromise
[5] 
https://blog.torproject.org/blog/deterministic-builds-part-two-technical-details



More information about the nix-dev mailing list