Michael J Gruber <g...@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 gits...@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 <gits...@pobox.com> sig 3 713660A7 2011-10-01 Junio C Hamano <gits...@pobox.com> sig 3 713660A7 2011-10-01 Junio C Hamano <gits...@pobox.com> sig F3119B9A 2011-10-01 Junio C Hamano <gits...@pobox.com> sig 493BACE4 2011-10-04 H. Peter Anvin (hpa) <h...@zytor.com> sig 93674C40 2011-10-04 Theodore Y. Ts'o <ty...@mit.edu> sig 00411886 2012-07-20 Linus Torvalds <torva...@linux-foundation.org> sig C11804F0 2011-10-04 Theodore Ts'o <ty...@mit.edu> sig 02A80207 2011-10-05 Andrew Morton (akpm) <a...@linux-foundation.org> uid Junio C Hamano <ju...@pobox.com> sig 3 713660A7 2011-10-01 Junio C Hamano <gits...@pobox.com> sig F3119B9A 2011-10-01 Junio C Hamano <gits...@pobox.com> sig 493BACE4 2011-10-04 H. Peter Anvin (hpa) <h...@zytor.com> sig 00411886 2012-07-20 Linus Torvalds <torva...@linux-foundation.org> sig C11804F0 2011-10-04 Theodore Ts'o <ty...@mit.edu> uid Junio C Hamano <j...@google.com> sig 3 713660A7 2011-10-01 Junio C Hamano <gits...@pobox.com> sig F3119B9A 2011-10-01 Junio C Hamano <gits...@pobox.com> sig 493BACE4 2011-10-04 H. Peter Anvin (hpa) <h...@zytor.com> sig 00411886 2012-07-20 Linus Torvalds <torva...@linux-foundation.org> sub 4096R/833262C4 2011-10-01 sig 713660A7 2011-10-01 Junio C Hamano <gits...@pobox.com> sub 4096R/96AFE6CB 2011-10-03 [expires: 2017-09-20] sig 713660A7 2015-09-21 Junio C Hamano <gits...@pobox.com> sub 4096R/B3F7CAC9 2014-09-20 [expires: 2017-09-19] sig 713660A7 2014-09-20 Junio C Hamano <gits...@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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
