Why? What is the benefit of doing so when everyone wants a deterministic build?
I'd have thought that deterministic builds are really simple unless your toolkit ecosystem is FUBAR. After all, a compiler is a simple function from input to output (unless the FUBAR ecosystem syndrome arises, as I said).
Who tried to poke them how, and what happened?
"Using the same source and same project directory results in the same pattern of difference in the block starting at 0002CBAC, as the pattern shown between my build from the correct project directory and the original file. This means that this difference is a normal result of the compilation process, and can be considered harmless from our point of view"
I share the author's belief it's probably benign, and on the assumption that the source code contains no crazy obfuscated magic, it'd be pretty hard to actually hide malicious code or behaviour there.
Still if they want to be thorough (and they should), I'd have liked a bit more explanation than waving it away with a "well these bytes seem to change all the time, so that's okay then". That's not really a justification, it's just an explanation. And it's not okay.
The last bit is the signature, which you can't duplicate, but you can also just take out, as it's not code. But, if you're paranoid about that, zero-out or remove the signature after verifying it.
... as long as you also trust the compiler not to introduce any backdoor... (cf. Reflections on Trusting Trust)
So let me throw out an idea that might help justify this trust too. Compile the same TrueCrypt sources with a totally different compiler, then use both binaries in a deterministic way and compare the raw encrypted result. (I'm assuming here that the same encryption keys and data will give the same result, but don't know for sure if that's true.)
Lets all just stop right here. No, dont mention that cross-compile with different compilers and compare. Just everyone stop.
I seem to remember retrieving from a BBS way back when, an MS-DOS shareware pascal or C compiler of some kind that would leave behind a serial number foot print in executables that the author said he could use to prove that an unregistered version of his product was used. I wish I could remember it now, though
I think we're thinking of the A86 shareware assembler:
Import the .asc file in the keyring (File > Import certificates).
Now you should mark the key as trusted: right click on the TrueCrypt Foundation public key
in the list under Imported Certificate tab > Change Owner Trust, and set it as I believe checks are casual.
You should also generate your own key pair to sign this key in order to show you really trust
it and get a nice confirmation when verifying the binary. The PGP signature of the binary can be downloaded
through the button PGP Signature, which makes you
download TrueCrypt Setup 7.1a.exe.sig over HTTPS
(*although with the NSA in the middle, it might not
mean much*).
cross-referencing the pgp signature with at least one other (public) source would go a long way toward allaying those concerns (that the HTTPS might not mean much).
this criticism is in no way meant to detract from the rest of the work, and i mean only to refer to pgp sig verification best practices here.
That's how science works.
How about an vmware/vbox image setup explicitly for that purpose? Not feasible for windows due to licencing issues, i guess.
Also, huge kudos for the effort going into this work. Thanks!