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

Michael J Gruber [off-list ref] writes:

Jeff King venit, vidit, dixit 27.01.2016 09:09:

quoted

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 [off-list ref]
sig 3        713660A7 2011-10-01  Junio C Hamano [off-list ref]
sig 3        713660A7 2011-10-01  Junio C Hamano [off-list ref]
sig          F3119B9A 2011-10-01  Junio C Hamano [off-list ref]
sig          493BACE4 2011-10-04  H. Peter Anvin (hpa) [off-list ref]
sig          93674C40 2011-10-04  Theodore Y. Ts'o [off-list ref]
sig          00411886 2012-07-20  Linus Torvalds [off-list ref]
sig          C11804F0 2011-10-04  Theodore Ts'o [off-list ref]
sig          02A80207 2011-10-05  Andrew Morton (akpm) [off-list ref]
uid                  Junio C Hamano [off-list ref]
sig 3        713660A7 2011-10-01  Junio C Hamano [off-list ref]
sig          F3119B9A 2011-10-01  Junio C Hamano [off-list ref]
sig          493BACE4 2011-10-04  H. Peter Anvin (hpa) [off-list ref]
sig          00411886 2012-07-20  Linus Torvalds [off-list ref]
sig          C11804F0 2011-10-04  Theodore Ts'o [off-list ref]
uid                  Junio C Hamano [off-list ref]
sig 3        713660A7 2011-10-01  Junio C Hamano [off-list ref]
sig          F3119B9A 2011-10-01  Junio C Hamano [off-list ref]
sig          493BACE4 2011-10-04  H. Peter Anvin (hpa) [off-list ref]
sig          00411886 2012-07-20  Linus Torvalds [off-list ref]
sub   4096R/833262C4 2011-10-01
sig          713660A7 2011-10-01  Junio C Hamano [off-list ref]
sub   4096R/96AFE6CB 2011-10-03 [expires: 2017-09-20]
sig          713660A7 2015-09-21  Junio C Hamano [off-list ref]
sub   4096R/B3F7CAC9 2014-09-20 [expires: 2017-09-19]
sig          713660A7 2014-09-20  Junio C Hamano [off-list ref]

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.