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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]