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

>Developers have a perfect method for making their own software malicious: bugdoors.

I think rather than malicious developers the focus is on malicious build machines. How many things are built solely via CI these days, on machines that nobody has ever seen, using docker images that nobody has validated?

It's much easier to imagine a malicious provider (as in Sourceforge bundling in adware) than malicious developers, I think.

But yes, you're right that reproducible builds don't remove the need to trust the source.

>You have to trust the developer, but in theory, reproducible builds could be used to convince yourself their build server hasn't been hacked. This isn't really necessary or useful, you can already produce a trustworthy binary by just building the source code yourself.

This is pretty much all false though - not only the "just" part, as setting up a proper build environment is pretty non-trivial for many projects, and building everything from source is a task only the most dedicated Gentoomen would take up; you can also think of reproducible builds as a "litmus test". If you can, with reasonable accuracy, check whether a build machine is compromised at any time, you have a much greater base on which to trust it and its outputs. The benefits of having build machines probably shouldn't need explaining.

>You can't just pick one or two consensus servers, because then an attacker can stop you getting updates by compromising any one of them. You will have to do something like choose a lot of servers, and only require 51% to agree.

>...

>The problem is now you've either just replaced build servers with killswitches, or just replicated the same potentially-compromised buildserver.

I really don't understand this argument; compromised infrastructure probably shouldn't be a regular occurrence, and even if so, automated killswitches seem like the vastly more preferable option, no?

> What isn’t clear is what benefit the reproducibility provides. The only way to verify that the untrusted binary is bit-for-bit identical to the binary that would be produced by building the source code, is to produce your own trusted binary first and then compare it. At that point you already have a trusted binary you can use, so what value did reproducible builds provide?

That's not the interesting case. The interesting case is when the untrusted binary doesn't match the binary produced by building the source code. Assuming that the untrusted binary has been signed by its build system, you now have proof that the build system is misbehaving. And that proof can be distributed and reproduced by everyone else.

Once Debian is fully reproducible, I expect several organizations (universities, other Linux distribution vendors, governments, etc) to silently rebuild every single Debian package, and compare the result with the Debian binaries; if they find any mismatch, they can announce it publicly (with proof), so that the whole world (starting with the Debian project itself) will know that there's something wrong. This does not need any complicated consensus mechanism.

> More often, attackers want signing keys so they can sign their own binaries, steal proprietary source code, inject malicious code into source code tarballs, or malicious patches into source repositories.

In Debian, compromising the build server is not enough to inject malicious code into source code tarballs or patches, since the source code is also signed by the package maintainer. Unexpected changes on which maintainer signed the source code for a given package could be flagged as suspicious.

The only attack left from that list, at least for Debian, would be for the attacker to sign their own top-level Release file (on Debian, individual packages are not signed, instead a file containing the hash of a file containing the hash of the package is what is signed). But the attacker cannot distribute the resulting compromised packages to everyone, since those who rebuild and compare every package would notice it not matching the corresponding source code, and warn everyone else.

> Reproducibility is technically pointless, because you still have to trust the developer, and they can still add backdoors.

Builder != developer - and with reproducible builds, you no longer beed to trust the builder. CI is commonly used for the final distributable builds and you can't always trust the CI server. Even if you do, many rely on third party thingd like docker images - if the base build image gets compromised, code could trivially be injected into builds running on it and without reproducible builds, that would not be detectable.

As a developer, it would be quite reassuring to build my binary (which I already do for testing) and compare the hash with the one from the CI server to confirm nothing has been tampered with. As a bonus, distro maintainers who have their own CI can also check against my hashes to verify their build systems aren't doing something fishy (malicious or otherwise).

This is slightly different thing. Nix and NixOS are trying to solve multiple things, and that's what it might be a bit confusing.

Many people don't realize that, but if you get for example mentioned project from github and I do and we compile it on our machines we get a different file (it'll work the same but it won't be exactly the same).

Say we use the same dependencies, we still will get a different files, because maybe you used slightly different version of the compiler, or maybe those dependencies were compiled with different dependencies or compilers. Maybe the project while building inserts a date, or pulls some file. There are million ways that we would end up with different files.

The goal here is to get bit by bit identical files and it's like a Holy Grail in this area. NixOS just appears to achieved that and all packages that come with the system are now fully reproducible.

> As a developer, it would be quite reassuring to build my binary (which I already do for testing) and compare the hash with the one from the CI server to confirm nothing has been tampered with.

That makes sense! However, this is not a good argument for reproducible builds, because you can already do that today.

You already have to build a trusted binary locally for testing right? You're dreaming of being able to compare that against the untrusted binary so that you can make sure it's a trusted binary too - but you already have a trusted binary!

Okay - but it's a hassle, you don't want to have to do that, right? Too bad - reproducible builds only work if someone reproduces them. You're still going to have to replicate it somewhere you trust, so you gained practically nothing.