Strictly speaking, it lets you know that your compiler binary matches its source. You can then read the source to decide if you trust the compiler (and others can audit it, can audit binaries generated from it, &c, &c). At which point, as raving-richard says, you can start to trust that your other utilities match their source as well. Which source also should be audited, &c, &c.
Right, my point is having deterministic builds of firefox aren't even really needed for this. If you trust your compiler, you trust your compiler. What does it matter if you have a non-deterministic build of a utility. You trust what is non-deterministically building it.
As this stands, if you deterministically build firefox, you just know that if your toolchain is corrupted, it is consistent. :)
If you trust your compiler you can verify that your build is the safely based on the source that you have. If the build is deterministic then you could verify that the binary being distributed to the masses isn't compromised by building the same file yourself and seeing that it is the same.
Right, and my question is essentially if this is "putting the cart before the horse." Do Mozilla have efforts in place to establish trust of their compilers? (I expanded on my response below. I really wish I knew the correct way to "merge" conversation trees here. Is there a good protocol for that?)
esrauch has it, but it's a point worth stressing: it gives many more people the opportunity to notice any discrepancy in common tool chains, as well as adding assurance for those who aren't building their own.
I can see how it helps. I'm still curious by how much. Consider, if everyone's common tool chain is untrustworthy, then this solves nothing.
This is why the "docker" idea worries me. It is basically counter productive. Just moves the "trust" to a whole harder thing to verify.
And the reason I was focusing on the compiler point, is to my knowledge nobody has established that the common compilers are trustworthy. At least not the ones in use at large. Until that happens, we're back to my first point. Which is to say that we may not be trustworthy.
Again, to be clear, I see there is benefit to knowing that we are all of the same trustworthiness. Having "reproducible" builds that don't match is an indication that something is definitely wrong. Definitely a worthy effort. Just, having reproducible builds that do match doesn't really tell you much about the trustworthiness of the application. Specifically, it only tells you that it is as trustworthy as another build. (Similar to the boolean logic that trips folks up all of the time that False \implies True is true, as is False \implies False.)
Unless, of course, I'm still misunderstanding something.
I had to think about this for more than a second. :) I think I see what you mean. Specifically, if N = 2, this doesn't do much. However, as soon as you have more folks that agree, then the first time someone disagrees, you have a good spot for auditing. Right?
I still can't see how the docker idea helps this purpose right off.
