Live data from Hacker News

Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible

discourse.nixos.org

11–20 of 232 posts

Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible

#11
This really deserves more love.

Who remembers Ken Thompson's "Reflections on Trusting Trust"?

The norm today is auto-updating, pre-built software.

This places a ton of trust in the publisher. Even for open-source, well-vetted software, we all collectively cross our fingers and hope that whoever is building these binaries and running the servers that disseminate them, is honest and good at security.

So far this has mostly worked out due to altruism (for open source maintainers) and self interest (companies do not want to attack their own users). But the failure modes are very serious.

I predict that everyone's imagination on this topic will expand once there's a big enough incident in the news. Say some package manager gets compromised, nobody finds out, and 6mo later every computer on earth running `postgres:latest` from docker hub gets ransomwared.

There are only two ways around this:

- Build from source. This will always be a deeply niche thing to do. It's slow, inconvenient, and inaccessible except to nerds.

- Reproducible builds.

Reproducible builds are way more important than is currently widely appreciated.

I'm grateful to the nixos team for being beating a trail thru the jungle here. Retrofitting reproducibility onto a big software project that grew without it, is hard work.

Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible

#13
post #7
post #2

Can anyone comment on the significance of this accomplishment, and why it was hard to achieve before? I (naively, apparently) assumed this had been possible with open-source toolchains for a long time.

Just recently, there were large non-reproducible projects: python, gcc. Not sure where is the history of non-r13y. --- There is Debian initiative to create bit-to-bit reproducible builds for all their software (well, all critical). https://reproducible-builds.org/ R13y is akin to "computer proofs" in math -- if you don't have it, that's fine, but if you have it, that's awesome. There are practical reasons to favor re…

Being bit-for-bit reproduceable means you could do fun things like distribute packages as just sources and a big blob of signatures, and you can still run only signed binaries.

Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible

#14
post #5
post #2

Can anyone comment on the significance of this accomplishment, and why it was hard to achieve before? I (naively, apparently) assumed this had been possible with open-source toolchains for a long time.

The code has to be changed so that things like system specific paths, time of compilation, hardware, etc. Don’t cause the compiled program to be unique to that computer (meaning compiling the same code on a different computer will give you a file that still works but has a different md5 hash) By being able to reproduce the file completely, down to identical md5 hashes, you know you have the same file the creator has,…

Does this mean that the code cannot be built with CPU specific optimisations (march option with gcc)

Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible

#16
post #2

Can anyone comment on the significance of this accomplishment, and why it was hard to achieve before? I (naively, apparently) assumed this had been possible with open-source toolchains for a long time.

The GCC developers in particular were hostile to such efforts for a long time, IIRC. (This is a non-trivial issue because randomized data structures exist and can be a good idea to use: treaps, universal hashes, etc. I’d guess it also pays for compiler heuristics to be randomized sometimes. Incremental compilation is much harder to achieve when you require bit-for-bit identical output. Even just stripping your compil…

How/why was the randomness part not "solveable" via using fixed seeds?

Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible

#17
post #2

Can anyone comment on the significance of this accomplishment, and why it was hard to achieve before? I (naively, apparently) assumed this had been possible with open-source toolchains for a long time.

The GCC developers in particular were hostile to such efforts for a long time, IIRC. (This is a non-trivial issue because randomized data structures exist and can be a good idea to use: treaps, universal hashes, etc. I’d guess it also pays for compiler heuristics to be randomized sometimes. Incremental compilation is much harder to achieve when you require bit-for-bit identical output. Even just stripping your compil…

> Incremental compilation is much harder to achieve when you require bit-for-bit identical output

Presumably, incremental compilation is only for development. For release, you would do a clean build, which would be reproducible.

> Even just stripping your compile paths from debug info is not entirely straightforward

Just use the same paths.

Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible

#18
post #5

Earlier quoted context omitted.

The code has to be changed so that things like system specific paths, time of compilation, hardware, etc. Don’t cause the compiled program to be unique to that computer (meaning compiling the same code on a different computer will give you a file that still works but has a different md5 hash) By being able to reproduce the file completely, down to identical md5 hashes, you know you have the same file the creator has,…

Does this mean that the code cannot be built with CPU specific optimisations (march option with gcc)

Pretty much. But hopefully x86_64 feature levels will provide the benefits of native builds to a reasonable extent.

Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible

#19
post #5

Earlier quoted context omitted.

The code has to be changed so that things like system specific paths, time of compilation, hardware, etc. Don’t cause the compiled program to be unique to that computer (meaning compiling the same code on a different computer will give you a file that still works but has a different md5 hash) By being able to reproduce the file completely, down to identical md5 hashes, you know you have the same file the creator has,…

Does this mean that the code cannot be built with CPU specific optimisations (march option with gcc)

The software doesn't suddenly become incompatible with CPU-specific optimisations (or many other compiler flags that change its output), but if you do so, you won't be able to reproduce the distribution binaries. Distributions don't enable CPU-specific optimisations anyway, since they want to be usable on more than one CPU model.

Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible

#20
post #5

Earlier quoted context omitted.

The code has to be changed so that things like system specific paths, time of compilation, hardware, etc. Don’t cause the compiled program to be unique to that computer (meaning compiling the same code on a different computer will give you a file that still works but has a different md5 hash) By being able to reproduce the file completely, down to identical md5 hashes, you know you have the same file the creator has,…

Does this mean that the code cannot be built with CPU specific optimisations (march option with gcc)

Likely it means that with the same input arguments the end result is bit-by-bit identical. (As I understand the problems were hard to control output elements. So it was not enough to se the same args, set the same time, and use the same path and filesystem, because there were things that happened at different speeds, so they ended up happening at relative different elapsed times, so the outputs contained different timestamps, etc.)
Post reply on HN