windows binary for gnupg 1.4.11 // compilation instructions posted

[Robert J. Hansen]

On 9/16/2011 2:49 PM, vedaal at nym.hush.com wrote:
> Because then who is to say that it wasn't tampered with?

Who's to say the one on ftp.gnupg.org wasn't tampered with?  It would be
fairly easy to make a version of GnuPG that always reported itself as
having a good signature.  (See, e.g., Ken Thompson, _Reflections on
Trusting Trust_.  David A. Wheeler had an interesting solution to
Thompson's problem, but in the main Thompson's remarks are still quite
applicable. [1])

And if you're downloading source code and compiling from source -- how
do you know the source wasn't tampered with?  A back door could be
hidden inside the code, making sure that whenever you attempted to
verify... etc., etc.

> The whole point is to start with gnupg.org signed and verified 
> material, and then let the user take it from there.

You can't.  I hate to rain on the parade, but this is simply not
achievable.  At some point you have to accept something on faith.  The
only question is what you'll accept.

In the extreme case, let's say GnuPG hosts a Windows binary and posts an
MD5 sum of it.  How do you know the MD5 sum that's posted is accurate?
Werner's signature on it is meaningless: you don't have a trusted copy
of GnuPG you can use to verify the signature.  The posted MD5 sum could
have been tampered with and you wouldn't know.  Etc., etc.

Ultimately, you have to take something on faith -- whether it's "I
believe this MD5 sum is correct," or "I believe this binary is correct,"
or what-have-you.  That initial trust decision is what bootstraps the
entire process.

If an initial trust decision is necessary, why not host your own GnuPG
binary, or link to the binary on the ftp.gnupg.org site, or...?

> Although, [and am over my head here, so please correct if wrong], if 
> there *could* be a way of providing instructions on compiling, so 
> that the resultant compiled file would always have the same hash, 
> then it might make sense to host the compiled binary and the hash.

This is technically possible but highly daunting.  It involves opening
up a PE/COFF executable in a hex editor and looking at specific offsets
for timestamps, machine-specific identifiers, and so on -- and then
hard-coding those back to the values present in the original binary.  If
the resulting binary is bit-for-bit identical to the original, then
you've got a perfect copy.

This is generally not worth doing unless you're in some
way-beyond-the-next-level environment where you take supply-chain
assurance to crazed levels.



[1]  ... And David Shaw was the one who pointed me towards Wheeler's
paper in the first place, some time ago -- thanks.  :)