How to find and verify a trust path?

[Doug Barton]

I don't recall if anyone has mentioned http://pgp.cs.uu.nl/ yet. 
Tragically not available over https, but nowadays that isn't as much of 
an assurance as once thought, depending on your threat model of course. :)

More below ...

On 09/18/2013 02:37 PM, Philip Jägenstedt wrote:
> On Wed, Sep 18, 2013 at 10:23 PM, Peter Lebbing <peter at digitalbrains.com> wrote:
>> On 18/09/13 22:14, � wrote:
>>> If I assume that the Wayback Machine isn't part of a conspiracy against me
>>
>> I don't see how this is different than not verifying at all and "assuming
>> gnupg.org isn't part of a conspiracy against me".
>
> It's one more server which would have to be under the attacker's
> control, in addition to gnupg.org, Google cache, mailing list mirrors
> and whatever else one might find.

You can spend an enormous amount of time going further and further down 
the rabbit hole if you choose to. :)  At the end of the day the question 
becomes, "How much extra benefit does this extra work provide me, vs. 
the cost of any potential attack that not doing the work might permit?"

If you're running a GnuPG binary on a Windows system, then spending more 
than 2 minutes is probably 1:30 too long. As has been mentioned here 
before, unless you are qualified to audit all of the existing build tool 
chain binaries and related libs on your Unix-like OS even building the 
GnuPG package yourself after thoroughly verifying the signature/key for 
the source tarball is putting a whole lot of faith in the system. 
Admittedly in the case of something like a mainstream Linux or BSD 
system your trust is probably better placed by an order of magnitude, 
but it's still a lot of trust.

>> What is your threat model?
>
> When checking the GnuPG dist sig key, the risk is some third party
> modifying the source, i.e. that the code I'm getting is not from the
> same origin as all the gpg binaries everyone else is using and
> trusting with their secrets.

Sorry, all you've done there is restate the problem. What bad things are 
you concerned will happen to you if you use this non-standard source? 
You may think that's a totally obvious question, but it's not. And see 
above for why it's probably the wrong question anyway.

>> Alternatively, if you use a Linux distro: simply install it with the package
>> manager. You already implicitly trust that anyway. If somebody got inside the
>> package manager, they don't need to bother to attack GnuPG specifically.
>>
>> I suppose technically you're also trusting the maintainer for the package. No
>> worse than trusting any other maintainer, I think. They all have access to the
>> binaries you run.
>
> I wanted to try 2.1.0beta3 which isn't in Debian testing, but using
> the package manager (which I trust) as yet another cross-check sounds
> reasonable, if some package happened to include the dist sig key, but
> I haven't found it.

When I was a FreeBSD developer I tried to get the PTB interested in 
adding standard (albeit opt-in) support for PGP signatures in our 
ports/packages system. For the source side (ports) I wanted to include 
the PGP signatures from the distributor of the tarball. On the 
pre-compiled packages side I wanted our package creation system to 
create a signature for the package. I even included a POC for the former 
in the ports I maintained. While the security conscious users liked it, 
the general consensus was that the SHA-256 checksums we were already 
using to verify the authenticity of the source tarballs was enough.

My counter-argument was that this is insufficient, since it relies on 
the (volunteer) maintainer of the port to provide thorough review of new 
source packages, which is something we had consistency problems with 
even amongst those with the best of intentions. The Linux package 
systems I'm familiar with (and admittedly that's not many) seem to share 
the same "reliability" (pardon the pun) issue. If the maintainer is the 
one who wants to pwn me, that would theoretically be possible, at least 
for a time.

FWIW,

Doug