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

191–200 of 232 posts

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

#191

Post by goodpoint »

cesarb wrote: post #164
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…

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

> 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

This has been happening for many years. A lot of large companies that care about security and maintainability sign big contracts to with tech companies that often include indemnification.

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

#192

Post by Tabular-Iceberg »

schelling42 wrote: post #187
londons_explore wrote: post #184

Earlier quoted context omitted.

> and 6mo later every computer ... gets ransomwared. I'm really surprised such an attack hasn't happened already. It seems so trivial for a determined attacker to take over an opensource project (plenty of very popular projects have just a single jaded maintainer). The malicious compiler could inject an extra timed event into the main loop for the time the attack is scheduled to begin, but only if it's >3 hours away,…

How do you know it hasn't been done already? (with a more silent payload than ransomware) /s

What does the /s mean in this context?

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

#193

Post by eru »

taviso wrote: post #176
eru wrote: post #175

Earlier quoted context omitted.

With the reproducible build, you can start using the untrusted binary while you are still building your trusted one. You can also have ten people on the internet verify the untrusted binary. With signatures, adding more people doesn't help.

> With the reproducible build, you can start using the untrusted binary while you are still building your trusted one. That's not how it works, you have to reproduce it before it becomes trusted. > You can also have ten people on the internet verify the untrusted binary. Sure, then we have to build a complex consensus system that introduces a bunch of unsolved problems. My opinion is that this just isn't worth it, th…

> That's not how it works, you have to reproduce it before it becomes trusted.

Eh, there's stuff you can do with software before you trust it. Eg you can start pressing the CDs or distributing the data to your servers. Just don't execute it, yet.

> Sure, then we have to build a complex consensus system that introduces a bunch of unsolved problems. My opinion is that this just isn't worth it, there is practically nothing to gain and it's really really hard.

It's the same informal system that keeps eg debian or the Linux kernel secure currently:

People don't do kernel reviews themselves. They just use the official kernel, and when someone finds a bug (or spots otherwise bad code), they notify the community.

Similar with reproducible builds: most normal people will just use the builds from their distro's server, but independent people can do 'reviews' by running builds.

If ever a build doesn't reproduce, that'll be a loud failure. People will complain and investigate.

Reproducible builds in this scenario don't protect you from untrusted code upfront, but they make sure you'll know when you have been attacked.

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

#194

Post by tester756 »

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…

>There are only two ways around this:

>- Build from source. This will always be a deeply niche thing to do. It's slow, inconvenient, and inaccessible except to nerds.

if you trust the compiler :)

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

#195

Post by squiggleblaz »

taviso wrote: post #138
wildfire wrote: post #131

Earlier quoted context omitted.

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

How about if the system will only run signed builds? Couldn't you use it to verify the signed build by stripping the signature and comparing them?

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

#196

Post by adonovan »

mananaysiempre wrote: post #8
avalys wrote: post #2

Can 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.

The GCC developers in particular were hostile to such efforts for a long time, IIRC. (This is a non-trivial issue because randomized data structures exist and can be a good idea to use: treaps, universal hashes, etc. I’d guess it also pays for compiler heuristics to be randomized sometimes. Incremental compilation is much harder to achieve when you require bit-for-bit identical output. Even just stripping your compil…

GCC used to attempt certain optimizations (or more generally, choose different code-generation strategies) only if there was plenty of memory available. We discovered this in the course of designing Google's internal build system, which prizes reproducibility.

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

#197

Post by shawnz »

KirillPanov wrote: post #189
kzrdude wrote: post #186

Earlier quoted context omitted.

Aha.. don't all compilers behave the same way, with debug info? I mean it's worthwhile to fix, but that behaviour seems so standard.

No, rust leaks the path to the source code on the build machine. This path likely does not even exist on the execution machine, so there's absolutely no good reason for this leakage. It is very nonstandard. It is really, really annoying that the Rust team is not taking this problem seriously.

I don't think this is correct. Most compilers include the path to the source code on the build machine in the debug info, and it's a common problem for reproducible builds. This is not a rust-specific issue.

Obviously the binary can't contain paths from the execution machine because it doesn't know what the execution machine will be at compile time, and the source code isn't stored on the execution machine anyway. The point of including the source path in the debug info is for the developer to locate the code responsible if there's a crash.

See: https://reproducible-builds.org/docs/build-path/

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

#198

Post by 1MachineElf »

rswail wrote: post #153

Recently, President Biden put out an executive order that mandates that NIST et al work out, over the next year, an SBOM/supply chain mandate for software used by Federal departments. That's going to require the equivalent of "chain of custody" attestations along the entire build chain. Along with SOC and PCI/DSS and other standards, this is going to require companies and developers to adopt NixOS type immutable envi…

I doubt it will happen until NixOS or similar tool has a corresponding DISA STIG.

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

#199

Post by ghoward »

Tabular-Iceberg wrote: post #192
schelling42 wrote: post #187

Earlier quoted context omitted.

How do you know it hasn't been done already? (with a more silent payload than ransomware) /s

What does the /s mean in this context?

Not GP, but I think it indicates sarcasm?

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

#200

Post by Zetaphor »

Tabular-Iceberg wrote: post #192
schelling42 wrote: post #187

Earlier quoted context omitted.

How do you know it hasn't been done already? (with a more silent payload than ransomware) /s

What does the /s mean in this context?

/s is internet parlance to show that the message should be read in a sarcastic tone.
Post reply on HN