GPG public keys

Hello,

Can you please point me to the public GPG keys used for source code signing?

Thanks, Jamie

Jamie Evans <jamie@pixelrebel.com> writes:

I suspect that you are asking about our project, but instead of throwing you a fish, I'll show you how to catch one yourself.

In a copy of linux kernel repository I have lying around from a random past, I did this:

    $ git log --show-signature

and saw something like this:

    commit c6fa8e6de3dc420cba092bf155b2ed25bcd537f7
    merged tag 'arm64-fixes'
    gpg: Signature made Wed 07 Oct 2015 03:10:34 AM PDT using RSA key ID 84C16334
    gpg: Can't check signature: public key not found
    Merge: e82fa92 62c6c61
    Author: Linus Torvalds <torvalds@linux-foundation.org>
    Date:   Wed Oct 7 18:17:46 2015 +0100

        Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/li...

I do not have the public key with key ID 84C16334, but I can ask public keyservers. Put 0x84C16334 in "Search String" in pgp.mit.edu and click "Do the search!"--it would result in the key that was used to sign the merge request that resulted in this merge.

I also can do this:

    $ git tag -v v3.0

and I would see something like:

    object 02f8c6aee8df3cdc935e9bdd4f2d020306035dbe
    type commit
    tag v3.0
    tagger Linus Torvalds <torvalds@linux-foundation.org> 1311301049 -0700

    Linux 3.0

    w00t!
    gpg: Signature made Thu 21 Jul 2011 07:17:44 PM PDT using DSA key ID 76E21CBB
    gpg: Good signature from "Linus Torvalds (tag signing key) <torvalds@osdl.org>"
    ...

to find that Linus's tag signing key has ID 0x76E21CBB (I do have his key in my keyring, so this does not say "Can't check").

Perhaps you can do the same to whatever project you are interested in. For example, here is a starting point to do the same for our recent v2.6.4 tag:

    $ git tag -v v2.6.4
    gpg: Signature made Tue 08 Dec 2015 02:12:50 PM PST using RSA key ID 96AFE6CB
    gpg: Can't check signature: public key not found
    error: could not verify the tag 'v2.6.4'

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

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?

Thanks again for the reply.  Oh, and thanks for git! 

Cheers, Jamie

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

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.

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.

On Wed, Dec 9, 2015 at 2:04 PM, Jeff King <peff@peff.net> wrote:

With all of us pointing out 96AFE6CB being the right hash, you may or may not trust the list enough to also trust the key now.

But the mailing list server may be hacked and run a s/good-hash/bad-hash/g on each email such that we cannot tell you via email what the right hash of Junios key is.

That's why the web of trust is built using side channels, i.e. not just the internet. Usually people meet and check face-to-face if the other person is the person they claim to be and if their key checks out.

On Wed, Dec 09, 2015 at 02:24:17PM -0800, Stefan Beller wrote:

Who's to assume that I actually checked that 96AFE6CB is right? ;)

Actually, I don't typically verify Junio's tag signatures. I fetch and run "make" daily, far more often than he signs, so I would have been p0wned long ago.

-Peff

On Wed, Dec 09, 2015 at 05:43:36PM -0500, Jeff King wrote:

It might also be worthwhile to check that the signatures on kernel.org match the key in the repo. kernel.org autosigns the tarballs as well, so presumably that key matches what kernel.org has on file for Junio.

It may also be less important that the key really belongs to a human named Junio C Hamano than that the same key consistently signs tags and tarballs. I can't personally vouch for the human behind the signatures, but when building git from tarballs, I do check that the same key signed them.