[taeric]

That sounds tangential. The point is if two people build the same thing, they should be able to compare their builds to see if they are truly the same. If not, the argument is that one of them has a "tampered" environment.

In other words, if you don't know your compiled binary is the same as the distributed binary, you have no reason to think yours does not have a vulnerability added by the toolchain.

Unless I'm the one that is misunderstanding, of course. :)

[mrpdaemon]

Well it's a solution to the same underlying problem - that by running binaries compiled by a 3rd party you trust that they aren't adding in code to compromise your privacy (voluntarily or not). If you compile the application from source yourself you don't need that leap of faith - no need to compare identical binaries or have deterministic builds (which is not trivial as the bug report demonstrates).

[taeric]

I'm not sure your solution solves that. If Firefox has vulnerabilities in the source right now, you do little to protect yourself by compiling on your own. Even if you can verify that you and someone else produce the same binary, they could just both be vulnerable.

In fact, if you compile it yourself, unless you can verify the compile against a "known good" one, then you can't even be sure that your local toolchain hasn't been compromised. (I mean, sure, if you were a perfect auditor of your entire toolchain, then you could have some confidence here. You have to be perfect, though.)

Consider, you do a compile of Firefox and it is different than the one for download. Why? As things stand now, you don't know. And that is the problem.

[mpyne]

> If Firefox has vulnerabilities in the source right now, you do little to protect yourself by compiling on your own.

You do more to protect yourself than taking the same vulnerable source and compiling it with Mozilla's "reproducible build chain".

If the source itself is corrupt then having a verified build of malicious source is completely useless.

With Gentoo you can verify the source itself matches the "trusted" upstream source and then build it with your own trustworthy build chain.

And before you go "what if your build chain isn't trustworthy huh????" think about it a little further... if your own local build chain can't be trusted you're already screwed even before you download anything from mozilla.org, just as you'd be if you downloaded a "bit verified" binary from mozilla to run on your already-pwned local operating system.

[taeric]

No you don't. You do nothing to protect yourself from vulnerabilities in the code by compiling it yourself. Literally nothing.

You do protect yourself from vulnerabilities in their toolchain. And this is where the effort makes sense. If there are differences in the builds, then you can at least suspect one of you has a tampered environment. Right now, you have no way of knowing that one way or the other. You just have the joy of having done your own build.

My main question is still just one of magnitude. Consider, I have not had a wreck or other car mishap in 20 years. I could conclude that seatbelts, then, have not increased my safety really. I am not trying to make that claim, as I feel it is false. So, my question here is essentially, how much safer would this really make things? (Or trustworthy, if you'd rather that term.)

[hyperion2010]

Fellow gentoo user here. Gentoo does not protect you from Trusting Trust attacks (mentioned above). But then again neither do reproducible builds, because you still have to trust the original compiler. Reducing the variance (to zero in this case) by using a deterministic build system DOES protect against compromise of everything except for the original build environment. Yes, that makes the original build env a target for attacks, but if we honestly believe we have a "trustable" reference build environment then those attacks are also exceptionally hard to pull off.