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

81–90 of 232 posts

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

#81

Post by IgorPartola »

zamadatix wrote: post #24
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…

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.

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

#82

Post by vore »

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…

I think using NetBSD might put you in the nerd camp ;-)

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

#83

Post by dane-pgp »

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…

> 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 updating a config file, so the only thing the node operators could achieve by boycotting the attestation process is temporarily inconveniencing people who used to rely on them (which is not a great return on investment for the reputation they burn in doing this).

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

#84

Post by smoldesu »

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…

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 liberally to quickly account for data integrity.

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

#85

Post by taviso »

smoldesu wrote: post #84
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…

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.

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

#86

Post by zamadatix »

bigiain wrote: post #64
zamadatix wrote: post #38

Earlier quoted context omitted.

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…

I guess reproducible builds solve some of the problems in the same way TLS/SSL solves some of the problems. Most of the world is happy enough with the soft guarantee of: “This is _probably_ your bank’s real website. Unless a nation state is misusing their control over state owned certificate authorities, or GlobalSign or LetsEncrypt or whoever has been p0wned.” Expecting binary black and white solutions to trust prob…

Reproducible builds solve many security problems for sure but but the problems it solves in no way help you if the maintainer is not alturistic or bad at security as originally stated. It helps tell you if the maintainers toolchain wasn't compromised and it does it AFTER the payload is delivered and you built your own payload not made by the maintainer anyways. It doesn't even tell you the transport/hosting wasn't compromised unless you can somehow get a copy of the source used to compile not made by the maintainer directly as the transport/hosting for the source they maintain could be as well.

Solving that singular attack vector in the delivery chain does nothing for solving the need to trust the altruism and self interest of maintainers. A good thing™? Absolutely, along with the other non security benefits, but has nothing to do with needing to trust maintainers or be in the niche that reviews source code when automatic updates come along as originally sold.

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

#87

Post by 1vuio0pswjnm7 »

kaba0 wrote: post #75
1vuio0pswjnm7 wrote: post #70

Earlier quoted context omitted.

"- 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…

You don’t use a browser or an office suite? Because those are a pain in the ass to compile (in terms of time).

Not just time, IME. Also 1. highly resource intensive, e.g., cannot compile on small form factor computers (easier for me to compile a kernel than a "modern" browser) and 2. brittle.

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

#89

Post by User23 »

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…

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

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

This is a little bit misleading. The actual paper[1] explains that you can't even trust source available code.

[1] https://users.ece.cmu.edu/~ganger/712.fall02/papers/p761-tho...

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

#90

Post by taviso »

dane-pgp wrote: post #83
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…

> 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?
Post reply on HN