Hacker News new | ask | show | jobs
by murderfs 42 days ago
Has there been a single publicly known attack that would have been prevented by this?
3 comments

Why should it only be valuable if the effects were to be publicly known?

There are plenty of places in industrial computing where reproducible builds have prevented subterfuge within the organizations themselves. Injecting binaries to do inf-/exfiltration is a long-standing industrial espionage activity which is of immense value to all users of the operating system - not just the consumer users.

My magic beans have prevented thousands of tiger attacks in top secret underground moon bases, never you mind that there's no way for me to actually prove this.

There's a certain irony in pushing for verifiable builds with completely unverifiable claims.

I've worked at several of the biggest targets for espionage, industrial or otherwise, and to the best of my knowledge, the only thing that's ever been discovered by their reproducible build efforts has been failing hardware on build reproducers

You probably don’t have enough experience with professional enterprise IT departments. Rootfs audits are a thing made a lot easier, and more effective, with reproducible builds.
Zero in Debian. They have enough other procedures to catch it.

Less diligent projects had it but there are easier ways to fix it

Several actually. Pypi is regularly targeted in this way.
But how many of those attackers also had the ability to publish a github commit but didn't to remain more stealthy.
This question is meaningless. Attackers will pick the best attack if they have more at their disposal. The fact that they didn't push a commit shows it's better not to. So closing that attack is good.
There is meaning. The difference in detection time does have meaning. If the improvement of detection time was marginal there may have been a different project time could have been invested in to make it even faster to catch such things than reproducible builds.
Hasn't happened in Debian
“Hasn’t happened” is quite naive. It happens internally - putting unscrupulous code in a company’s distro before torching the place is a surprisingly regular occurrence in places which have long since adopted Debian as a platform host. IT departments around the globe will benefit from this immensely.
And reproducible builds do not prevent that.

The one single fail point they prevent is infected build hosts.

That might be some reasonable benefit for the company if it is building it on public architecture, but for projects like Debian that insist build hosts are basically offline (package in, package out with no internet access during build process) it is very fringe benefit.

Nonsense, of course reproducible builds can be used by IT departments to catch nefarious behavior - they regularly do.