[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