There’s something very poetic about “unstable” being “reproducible”. It’s like controlled chaos.
I believe that's known as the Chaotic Good alignment.
Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible
101–110 of 232 posts
Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible
#102Earlier quoted context omitted.
Reproducability is an option to mitigate backdoors and incentive developers to operate openly. It's no panacea, but it makes a lot of sense in open-source projects where individual actors are going to represent your largest threat vector. That way, it becomes a lot harder to push an infected blob to main, even if it still is technically possible. Hashes are also "technically pointless", but we still implement them li…
Signatures are not technically pointless, they mean you only have to trust the developer - not the mirror operators. Reproducibility is technically pointless, because you still have to trust the developer, and they can still add backdoors.
Is it technically pointless if you view it as a check on your own build, rather than a check on the work of others?
You are obviously familiar with Bazel/Blaze etc. Wouldn't reproducibility be necessary for those systems to work well most of the time? I can think of exceptions (like PGO), but it seems useful to produce at least some binaries this way. Also covered in this: https://security.googleblog.com/2021/06/introducing-slsa-end...
Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible
#103Earlier quoted context omitted.
Reproducibility is necessary, but unfortunately not sufficient, to stop a "Trusting Trust" attack. Nixpkgs still relies on a bootstrap tarball containing e.g. gcc and binutils, so theoretically such an attack could trace its lineage back to the original bootstrap tarball, if it was built with a compromised toolchain.
Diverse double compilation should allow a demonstration that the toolchain is trustworthy.
And how about that hardware and firmware microcode?
Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible
#104Earlier quoted context omitted.
For some reason, many compilers and build scripts have traditionally been written in a way that's not referentially transparent (a pure function from input to output). Unnecessary information like the time of the build, absolute path names of sources and intermediate files, usernames and hostnames often would find their way into build outputs. Compiling the same source on different machines or at different times woul…
> There's no good reason (that I can think of) why this shouldn't have been the case all along Well, it's not like developers consciously thought "How can I make my build process as non-deterministic as possible?", it's just that by the time people started to become aware of the benefits of reproducibility, various forms of non-determinism had already crept in. For example, someone writing an archiving tool would be…
Thank you both. I was wondering the same thing.
Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible
#105Earlier quoted context omitted.
I don't know what reputation damage will happen, they're just third parties compiling code. There is no reputational damage for operating a malicious tor exit relay, why would this be different?
As I understand it, Tor does have a way of detecting whether an exit node is failing to connect users to their intended destination. (With TLS enforced, the only thing a malicious exit node could do is prevent valid connections). In any case, I don't think anyone is proposing that the attestation nodes be run by random anonymous people on the internet. It would make more sense to have half a dozen or so teams running…
The point was that a reproducible build doesn't mean you don't have to trust the developer.
Build servers rebelling was just an example of the additional complexities and attacks that it introduces, for very negligible benefit.
Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible
#106Earlier quoted context omitted.
No, it is not always the maintainer. Imagine you download a binary software package via HTTPS. In theory, the integrity of the download is protected by the server certificate. However, it is possible that certificates get hacked, get stolen, or that nation states force CAs to give out back doors. In that case, your download could have been changed on the fly with arbitrary alterations. Reproducible builds make it pos…
Same as when you download the source instead of the binary and see it reproducibly builds the backdoored binary. And at this point we're back to "Build from source. This will always be a deeply niche thing to do. It's slow, inconvenient, and inaccessible except to nerds." anyways. It's not that reproducible builds provide 0 value it's that they don't truly solve the trust problem as initially stated. They also have n…
> and inaccessible except to nerds.
So was most every part of computer hardware and software initially - this is just another milestone in that journey.
Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible
#107This 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 mo…
> 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. Actually, it's Debian guys who pushed reproducible build hard in the early days. They upstreamed necessary changes and also spread the concept itself. This is a two-decade long community effort. In turn, NixOS is mostly just wrapping those projec…
I think both efforts have been important and have benefitted each other. Nix has always had purity/reproducibility as tenets, but indeed it was Debian that got serious about it on a bit-for-bit basis, with changes to the compilers, tools like diffoscope, etc. The broader awareness and feasibility of reproducible builds then made it possible for Nix to finally realise the original design goal of a content-addressed rather than input-addressed store, where you don't need to actually sign your binary cache, but rather just sign a mapping between input hashes and content hashes.
Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible
#108Earlier quoted context omitted.
Signatures are not technically pointless, they mean you only have to trust the developer - not the mirror operators. Reproducibility is technically pointless, because you still have to trust the developer, and they can still add backdoors.
Reproducibility means you don't have to worry that the developer might have a backdoored toolchain (which also means that they can't pretend that a malicious toolchain added the malicious code without their knowledge). A talented developer might still be able to create a bugdoor which gets past code review, but that takes more effort and skill than just putting the malicious code into a local checkout and then saying…
Every major vendor has vulnerabilities introduced all the time, by accident! No talent is necessary to introduce a bugdoor, just malice.
You can already verify that a toolchain wasn't backdoored today, reproducible builds aren't necessary for that.
Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible
#109I think r13y has said the minimal ISO was less than 10 packages away from 100% over 2 years now. The long tail has finally been overcome! Huge news.
Some of the issues were really difficult to tackle, like the linux kernel generating random hashes.
The last mile was done by removing the use of ruby (which uses some random tmp directories) from the final image. Asciidoctor (ruby) was replaced with asciidoc (python).
Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible
#110Here’s an informative podcast episode on Nix with one of its maintainers, https://changelog.com/podcast/437.