[taeric]

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.

[dllthomas]

"Consider, if everyone's common tool chain is untrustworthy, then this solves nothing."

I don't quite agree - it more clearly establishes what tool chain people should be auditing!

[taeric]

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.