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 <[email protected]> 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
_______________________________________________
Gnupg-users mailing list
[email protected]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
