Hacker News Reader

Comment by emaste | Hacker News Reader

> That's a red herring. The diversity I referred to came from compiler transformations that provably enhance security

No. The work to get to a state where packages build reproducibly, in general, consists of removing timestamps, providing stable sort order for inputs, and similar cases. In the vast majority of cases the only diversity in a distro's package set comes from these sorts of differences. If addressing these cases results in a reproducible build, there was no meaningful diversity to begin with.

View on HN

You keep focusing on this one set of changes you do in the process when it has absolutely nothing to do with what I'm saying about the security argument for doing reproducible builds, diverse compiles, binary checks, etc. The big picture of what you're doing with what attacks are likely to come in.

If the goal is stopping subversion, I identified a bunch of other things you have to do. Some conflict with reproducible binaries where you avoid them or throw them away immediately. Some with strongest security... memory-safe languages, certified compilation, or highly-assured SCM... you aren't doing at all that I'm aware. Your attackers will try to hit all of this, though, rather than just do a compiler-compiler-subversion thing in MITM scenario. Hence the need for strong, holistic stuff instead of tactical hacks.

I'm sorry that we seem to be talking past each other. I don't disagree with what you write, my point is only that the reproducible builds effort has no real effect on aspects of it (such as binary diversity).

Of course there's a lot more that needs to be done to prevent or detect malfeasance, and while it's related, it's beyond the scope of the reproducible builds effort.

We could be talking past each other a bit. Ill end the tangent in that case. I agree the diversity effect is contentious (a smaller claim) and possibly out of scope for people doing these projects.

Reply on news.ycombinator.com