Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

discourse.nixos.org

Post reply on HN
Print view View original

131–140 of 232 posts

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

#131

Post by wildfire »

taviso wrote: post #108
dane-pgp wrote: post #100

Earlier quoted context omitted.

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.

> You can already verify that a > toolchain wasn't backdoored ) > today

How, exactly?

If we both compiled hello.c (a prototypical hello world program), and exchanged binaries; how would you verify my build wasn't malicious?

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

#132

Post by EE84M3i »

taviso wrote: post #77

I don't see a single comment doubting the value of reproducibility, so I'll be the resident skeptic :) I think build reproducibility is a cargo cult. The website says reproducibility can reduce the risk of developers being threatened or bribed to backdoor their software, but that is just ridiculous. Developers have a perfect method for making their own software malicious: bugdoors. A bugdoor (bug + backdoor) is a del…

Honestly I think the biggest benefit of reproducibility is just debuggability. We both check out the same git repo and build it, we can later hash the binary and compare the hashes to know we're running the exact same code.

On security, if you really care about compromised build servers you might as well just build from source yourself. I think reproducibility might matter most in systems where side loading is hard/impossible like app stores, but I'm not familiar with the current state of the art in terms of iOS reproducable builds and checking them.

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

#133

Post by zucker42 »

1vuio0pswjnm7 wrote: post #70
dcposch wrote: post #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 mo…

"- Build from source. This will always be a deeply niche thing to do. It's slow, inconvenient, and inaccessible except to nerds." I prefer compiling from source to binary packages. For me it is neither slow, incovenient nor inaccessible. Only with larger, more complex programs does compiling from source become a PITA. The "solution" I take is to prefer smaller, less complex programs over larger, more complex ones. If…

Don't take this the wrong way, but I think you qualify as a nerd. :)

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

#134

Post by IgorPartola »

xvector wrote: post #126
IgorPartola wrote: post #81

Earlier quoted context omitted.

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.

> It only takes one person to find a bit of malicious code, we don’t all need to review every single line. This is just objectively wrong. I have worked on projects at FAANG where entire teams did not spot critical security issues during review. You are very unlikely to spot an issue with just one pair of eyes. You need many if you want any hope of catching bugdoors.

You are misunderstanding what I am saying. I am saying that it only takes one person who finds a vulnerability to disclose it, to a first approximation. Realistically it’s probably closer to 2-3 since the first might be working for the NSA, the CCP, etc. I am making no arguments about what amount of effort it takes to find a vulnerability, just talking about how not every single user of a piece of code needs to verify it.

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

#135

Post by pilif »

staticassertion wrote: post #128
dcposch wrote: post #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 mo…

> Reproducible builds are way more important than is currently widely appreciated. Why? How will this help with the problems you're talking about? I can't come up with a single benefit to security from reproducible builds. It seems nice for operational reasons and performance reasons though.

> I can't come up with a single benefit to security from reproducible builds.

It is a means to allow to detect a compromised supply chain. If people rebuilding a distro cannot get the same hash as the distro shipping from the distributor, then likely the distributors infrastructure has been compromised

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

#136

Post by IgorPartola »

pabs3 wrote: post #122
remram wrote: post #92

Earlier quoted context omitted.

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.

The crev folks are working on a co-ordination system for incremental distributed code review: https://github.com/crev-dev/

I actually wonder if it’s possible to write code at such a macro level as to obfuscate, say, a keylogger in a huge codebase such that reviewing just a single module/unit would not reveal that something bad is going on.

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

#137

Post by mraza007 »

egberts1 wrote: post #130
mraza007 wrote: post #116

This might be a dumb question but what’s a reproducible build

The ability to recreate a binary image from the same set of source files and getting that binary to be identical to the package-provided binary. This is useful form of ensuring that nothing is amiss during compile/link time. Today’s GNU toolchain clutters the interior of binary files with random hash values, full file path (that you couldn’t recreate … easily), and random tmpfile directories. The idea is to make it e…

Oh okay thank you for explanation. You explained it really well

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

#138

Post by taviso »

wildfire wrote: post #131
taviso wrote: post #108

Earlier quoted context omitted.

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.

> You can already verify that a > toolchain wasn't backdoored ) > today How, exactly? If we both compiled hello.c (a prototypical hello world program), and exchanged binaries; how would you verify my build wasn't malicious?

I think the workflow you're proposing is to take some trusted source code, then compile it to make a trusted binary. Now compare the trusted binary to the untrusted binary provided by the vendor - If they're the same - then it must have been made by an uncompromised toolchain.

That does require reproducible builds, but here is how to do it without reproducible builds:

Take the trusted source code, then compile it to make a trusted binary. Now put the untrusted binary in the trash, cause you already have a trusted binary :)

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

#139

Post by remram »

pabs3 wrote: post #122
remram wrote: post #92

Earlier quoted context omitted.

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.

The crev folks are working on a co-ordination system for incremental distributed code review: https://github.com/crev-dev/

Crev is a great idea, unfortunately it is only really available for Rust right now.

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

#140

Post by [deleted] »

pabs3 wrote: post #118
taviso wrote: post #77

I don't see a single comment doubting the value of reproducibility, so I'll be the resident skeptic :) I think build reproducibility is a cargo cult. The website says reproducibility can reduce the risk of developers being threatened or bribed to backdoor their software, but that is just ridiculous. Developers have a perfect method for making their own software malicious: bugdoors. A bugdoor (bug + backdoor) is a del…

There are other solutions to the problem of trusting maintainers; namely incremental distributed code review. The Rust folks are working on that: https://github.com/crev-dev/ You still need Reproducible Builds and Bootstrappable Builds even if you have a fully reviewed codebase though.

[deleted]
Post reply on HN