Junio C Hamano venit, vidit, dixit 27.01.2016 19:10: > Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx, 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. Oops, I needed to refresh my copy of your key, sorry. You did sign 2.7.0 with the subkey 0xB0B5E88696AFE6CB >> 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@xxxxxxxxx> > sig 3 713660A7 2011-10-01 Junio C Hamano <gitster@xxxxxxxxx> > sig 3 713660A7 2011-10-01 Junio C Hamano <gitster@xxxxxxxxx> > sig F3119B9A 2011-10-01 Junio C Hamano <gitster@xxxxxxxxx> > sig 493BACE4 2011-10-04 H. Peter Anvin (hpa) <hpa@xxxxxxxxx> > sig 93674C40 2011-10-04 Theodore Y. Ts'o <tytso@xxxxxxx> > sig 00411886 2012-07-20 Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> > sig C11804F0 2011-10-04 Theodore Ts'o <tytso@xxxxxxx> > sig 02A80207 2011-10-05 Andrew Morton (akpm) <akpm@xxxxxxxxxxxxxxxxxxxx> > uid Junio C Hamano <junio@xxxxxxxxx> > sig 3 713660A7 2011-10-01 Junio C Hamano <gitster@xxxxxxxxx> > sig F3119B9A 2011-10-01 Junio C Hamano <gitster@xxxxxxxxx> > sig 493BACE4 2011-10-04 H. Peter Anvin (hpa) <hpa@xxxxxxxxx> > sig 00411886 2012-07-20 Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> > sig C11804F0 2011-10-04 Theodore Ts'o <tytso@xxxxxxx> > uid Junio C Hamano <jch@xxxxxxxxxx> > sig 3 713660A7 2011-10-01 Junio C Hamano <gitster@xxxxxxxxx> > sig F3119B9A 2011-10-01 Junio C Hamano <gitster@xxxxxxxxx> > sig 493BACE4 2011-10-04 H. Peter Anvin (hpa) <hpa@xxxxxxxxx> > sig 00411886 2012-07-20 Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> > sub 4096R/833262C4 2011-10-01 > sig 713660A7 2011-10-01 Junio C Hamano <gitster@xxxxxxxxx> > sub 4096R/96AFE6CB 2011-10-03 [expires: 2017-09-20] > sig 713660A7 2015-09-21 Junio C Hamano <gitster@xxxxxxxxx> > sub 4096R/B3F7CAC9 2014-09-20 [expires: 2017-09-19] > sig 713660A7 2014-09-20 Junio C Hamano <gitster@xxxxxxxxx> > > 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. "subkey" and "uid" are different things. You bind a subkey to your primary key with that self-signature. subkeys don't carry any other signatures. A primary key "carries" the uids, and whenever someone "signs your key" they in fact sign a specific uid - usually all, resulting in multiple signatures, one for each uid of the (primary) key. A key is usually considered trusted if it carries "a" signature from a trusted key. So, assuming my key carries a signature from a trusted key to at least one uid, it would be trusted no matter what (fake) uids I add to it later. >> 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. Michael -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html