On 9/16/2011 2:49 PM, ved...@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. :) _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users