Hacker News Reader

Comment by dane-pgp | Hacker News Reader

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?".

View on HN

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 :)

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?

Reply on news.ycombinator.com