Please have a look at David A. Wheeler’s page on Trusting trust [1], including his 2009 PhD dissertation [2], where he clearly demonstrates that it is possible to have trusted (not in the MS sense...) computers (I think).
You may also be interested in 'Countering "Trusting Trust"' on Schneier's website [3], which discusses a 2006 paper, also by Wheeler.
A C compiler is not a single executable. If you take gcc, compiling C code involves a preprocessor, a compiler, an assembler and a linker (and that's a.simplified view). To make matters worse, the assembler and the linker are not even part of the GCC source code, they're a separate project. That would likely make the process of DDC significantly more difficult than if the compiler was actually a single executable.
Also, there are other things involved in the whole process, like the CRT static objects, dynamic libraries and the dynamic loader. That's many more items to trust. You could even add the kernel to the list.
My memory on that was that it let you know whether you could trust your compiler. I couldn't remember if it extended ot the rest of the tool chain. Nor did I remember if it really hinged on deterministic builds. I'll have to retry it.
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.
If you trust your compiler, then you can read the source code and then trust the compiled executable. If you are worried, then you can build the rest of your tool chain from source...
My point is that that is the heart of the trust. You have to establish that before you can use any "deterministic" builds of your utilities to establish their trust.
You may also be interested in 'Countering "Trusting Trust"' on Schneier's website [3], which discusses a 2006 paper, also by Wheeler.
[1] http://www.dwheeler.com/trusting-trust/ [2] http://www.dwheeler.com/trusting-trust/dissertation/html/whe... [3] https://www.schneier.com/blog/archives/2006/01/countering_tr...