[deleted]
[deleted]
Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible
91–100 of 232 posts
Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible
#92Earlier quoted context omitted.
Unless you are going to be the equivalent of a full time maintainer doing code review for every piece of software you use you need to trust other software maintainers reproducible builds or not. Considering this is Linux and not even Linus can deeply review every change in just the kernel anymore that philosophy can't apply to meaningfully large software like Nixos.
No. I can review 0.1% of the code and verify that it compiles correctly and then let another 999 people review their own portion. It only takes one person to find a bit of malicious code, we don’t all need to review every single line.
That only works if you coordinate. With even more people, you can pick randomly and be relatively sure you've read it all, but I posit that 1) you don't pick randomly, you pick a part that is accessible or interesting to you (and therefore probably others) and 2) reading code locally is not sufficient to find bugs or backdoors in the whole.
Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible
#93Can 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.
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 completely right to think it is a useful feature to store the creation date of the archive in the archive's metadata. The idea that a user might want to force this value to instead be some fixed constant would only occur to someone later when they noticed that their packages were non-reproducible because of this.
But you're right; if the goal had been thought of from the start, there's no reason why every build tool wouldn't have supported this.
Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible
#94I really want to adopt Nix and NixOS for my systems but the cost of wrapping packages is just a little too high for me right now (or perhaps I'm out of date and a new cool tool that does it automatically is out). IMHO, a dependency graph-based build system that builds a hermetically sealed transitive closure of an app's dependencies that can be plopped into a rootfs via Nix [0] is far superior security wise to the tr…
Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible
#95Earlier 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.
Really? How does that accomplish more than proving the build is a fixed point? An attacker may well be aware of the fixed point combinator after all.
Edit: I think that tone may have come off as snarky, but I meant it as an honest question. If any expert can answer I'd really appreciate it.
Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible
#96This 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 projects with their own tooling, literally a cherry on the top. NixOS is disproportionately credited here.
Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible
#97I really want to adopt Nix and NixOS for my systems but the cost of wrapping packages is just a little too high for me right now (or perhaps I'm out of date and a new cool tool that does it automatically is out). IMHO, a dependency graph-based build system that builds a hermetically sealed transitive closure of an app's dependencies that can be plopped into a rootfs via Nix [0] is far superior security wise to the tr…
Did you try https://github.com/Mic92/nix-ld or https://nixos.org/manual/nixpkgs/unstable/#setup-hook-autopa... ?
Hm, this seems like a lower level set of tools that can be composed into something a bit more user-friendly (one of my personal complaints with Nix as well, despite being a big fan of the concept and overall execution. Nothing too steep that can't be learned eventually, but the curve exists). I'm wondering if there would be an audience for a higher level abstraction on top of Nix, or if one already exists.
Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible
#98Earlier quoted context omitted.
> If the server operators rebel, they can effectively veto a change the vendor wants to make. How often do you think there will be a change so controversial that teams who have volunteered to secure the update system will start effectively carrying out a Denial of Service attack against all the users of that distro? We also have to imagine that these malicious attestation nodes can easily be ignored by users just upd…
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 these nodes, with each team being known and trusted by the distro in question.
I'm not sure what the costs/requirements would be for running one of these nodes, but it might be possible for distros to each run a node dedicated to building each other's distros (or at least the packages that are pushed as security updates to stable releases).
Alternatively, individual developers that already work on a distro can offer to build packages on their own machines and contribute signed hashes to a log maintained by the distro itself.
Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible
#99Earlier quoted context omitted.
Unless you are going to be the equivalent of a full time maintainer doing code review for every piece of software you use you need to trust other software maintainers reproducible builds or not. Considering this is Linux and not even Linus can deeply review every change in just the kernel anymore that philosophy can't apply to meaningfully large software like Nixos.
You can't solve this problem without having a full history of code to inspect (unless you are decompiling), reproducibility is the first step and bootstrapability is the second step. Then we refine the toolchains and review processes to ensure high impact code is properly scrutinized. What we can't do is throw our hands up and say anyone who compromises the toolchain deep enough is just allowed to win. It will happen…
https://github.com/fosslinux/live-bootstrap is another approach, bootstrapping from a tiny binary seed that you could hand-assemble and type in as hex. But it doesn't address the dependency on the underling OS being trustworthy.
Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible
#100Earlier 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.
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 "How did that get there?".