Re: GPG public keys

[Jeff King <peff@peff.net>]

On Wed, Dec 09, 2015 at 09:03:47AM -0800, Jamie Evans wrote:

> Thanks, Junio, for the tutorial!  I had tried to lookup the key, but
> failed to put the ‘0x’ at the head.

An easier way to get keys is just:

  $ gpg --recv-keys 96AFE6CB
  gpg: requesting key 96AFE6CB from hkp server keys.gnupg.net
  gpg: key 713660A7: public key "Junio C Hamano <gitster@pobox.com>" imported
  [...etc...]

You may need to drop a keyserver into your config, like:

  echo "keyserver keys.gnupg.net" >>~/.gnupg/gpg.conf

It doesn't really matter which one you use. Keyservers aren't
authoritative. They are just a convenience for grabbing the key data,
and most of the major ones share keys with each other. The real security
comes from the signatures which you get along with the keys.

> I was actually verifying the signature on a tarball release.  Just
> curious, how do I know the key in the database really belongs to you?
> It’s has your name and email, but what’s to keep an imposter from
> creating a key with your name on it and posting it to the database?  I
> guess all the signatories on your key are others vouching for your
> key?

Right. Now that I've got Junio's key from the command above, I can do:

  gpg --list-sigs 96AFE6CB

Of course you won't have those keys either. You can recursively recv-key
them, but that doesn't help if you don't trust them. The same imposter
can create a network of plausible-looking keys and upload them.

In an ideal world you sign somebody else who signs somebody else who
signs Junio's key, and therefore you (probably trust it)[1]. But of
course bootstrapping that process is hard.

In practice, the simplest thing is probably to notice that all of the
git releases since v1.7.1.4 are signed by 96AFE6CB. If there was an
imposter, presumably somebody would have noticed by now and complained.

Of course you can't just fetch the v1.7.1.4 tag _now_, because the same
person impersonating the most recent tag could also be impersonating
(and back-dating) the older tags. But you could fetch it now, store it
somewhere trusted (e.g., on your laptop), and wait two weeks. If you
find no public outcry over hacked git, then it is probably OK to assume
that is the real key.

-Peff

[1] There are some cool tools to visualize the trust chains.
    Unfortunately this one does not seem to have Junio's latest key, but
    here is an example going from my key to the key Linus uses to sign
    the kernel:

      http://pgp.cs.uu.nl/mk_path.cgi?FROM=90F6F6B8&TO=00411886&PATHS=trust+paths

    Of course somebody can impersonate that tool, too. :) But you can
    fetch all of the individual keys in a path and verify
    cryptographically that the path exists.