Re: [RFC] tag-ref and tag object binding

[Junio C Hamano <gitster@pobox.com>]

Michael J Gruber <git@drmicha.warpmail.net> writes:

> Jeff King venit, vidit, dixit 27.01.2016 09:09:
>
>> The bigger issue is that gpg seems to give us only _one_ uid, when there
>> may be several. E.g., Junio's v2.7.0 is signed by 96AFE6CB, which is a
>> sub-key that has several uids associated with it. The one that "git
>> verify-tag --raw" shows from gpg is gitster@pobox.com, which is good,
>> but I think that's just because it happens to be the first uid. Or maybe
>> there is some gpg arcana going on that I don't know about.
>
> You do not sign with a uid, you sign with a (sub)key, and the tag is
> signed with Junio's primary key. His subkey is encryption only.

Hmm, actually I meant to sign my tags with signing subkey, not the
primary one, but I may have made a mistake.

> You do sign a uid.
>
> So, if you want to be sure that a tag is signed "with a specific uid" by
> relying on signatures from a set of signers, you would really need to
> check that the key that signed the tag has a signature on the correct
> uid. Having a signed key with the right uid in it doesn't mean much
> unlss the right uid is signed.
>
> E.g., I have a key with many signatures, and I could have Junio's uid on
> it in a minute without invalidating any of those signatures.

I have signatures on my primary key from others, and my signing key
is signed by my primary key and by no other keys.  Here is an
abbreviated output from running "gpg --list-sigs 96AFE6CB":

pub   4096R/713660A7 2011-10-01
uid                  Junio C Hamano <gitster@pobox.com>
sig 3        713660A7 2011-10-01  Junio C Hamano <gitster@pobox.com>
sig 3        713660A7 2011-10-01  Junio C Hamano <gitster@pobox.com>
sig          F3119B9A 2011-10-01  Junio C Hamano <gitster@pobox.com>
sig          493BACE4 2011-10-04  H. Peter Anvin (hpa) <hpa@zytor.com>
sig          93674C40 2011-10-04  Theodore Y. Ts'o <tytso@mit.edu>
sig          00411886 2012-07-20  Linus Torvalds <torvalds@linux-foundation.org>
sig          C11804F0 2011-10-04  Theodore Ts'o <tytso@mit.edu>
sig          02A80207 2011-10-05  Andrew Morton (akpm) <akpm@linux-foundation.org>
uid                  Junio C Hamano <junio@pobox.com>
sig 3        713660A7 2011-10-01  Junio C Hamano <gitster@pobox.com>
sig          F3119B9A 2011-10-01  Junio C Hamano <gitster@pobox.com>
sig          493BACE4 2011-10-04  H. Peter Anvin (hpa) <hpa@zytor.com>
sig          00411886 2012-07-20  Linus Torvalds <torvalds@linux-foundation.org>
sig          C11804F0 2011-10-04  Theodore Ts'o <tytso@mit.edu>
uid                  Junio C Hamano <jch@google.com>
sig 3        713660A7 2011-10-01  Junio C Hamano <gitster@pobox.com>
sig          F3119B9A 2011-10-01  Junio C Hamano <gitster@pobox.com>
sig          493BACE4 2011-10-04  H. Peter Anvin (hpa) <hpa@zytor.com>
sig          00411886 2012-07-20  Linus Torvalds <torvalds@linux-foundation.org>
sub   4096R/833262C4 2011-10-01
sig          713660A7 2011-10-01  Junio C Hamano <gitster@pobox.com>
sub   4096R/96AFE6CB 2011-10-03 [expires: 2017-09-20]
sig          713660A7 2015-09-21  Junio C Hamano <gitster@pobox.com>
sub   4096R/B3F7CAC9 2014-09-20 [expires: 2017-09-19]
sig          713660A7 2014-09-20  Junio C Hamano <gitster@pobox.com>

So I understand that the way you trust 96AFE6CB has to be indirect.
You may have somebody's key you know belongs to that somebody you
trust (say, Linus) in the list of signers of 713660A7 (my primary),
and you know 96AFE6CB is a key I use because it is signed by my
primary key.

You can add a subkey to your keyring a uid that says "Junio", but
the signature on that subkey would not have a signature by me you
can verify by following the web of trust.  You are correct to point
out that "this key claims to be by somebody, and it has some
signature" is not a sufficient reason for you to trust it.

> That one is easy already by setting "GNUPGHOME" to a special dir with a
> small keyring and tight trust settings (or having a dedicated account on
> the incoming side in the first place).

Yes, I understand that the above is how automated services per
project should be set up, with a dedicated verification keyring that
holds keys the project trusts.