From: Michael J Gruber <git@drmicha•warpmail.net>
To: Junio C Hamano <gitster@pobox•com>
Cc: Jeff King <peff@peff•net>, Santiago Torres <santiago@nyu•edu>,
Git <git@vger•kernel.org>
Subject: Re: [RFC] tag-ref and tag object binding
Date: Wed, 27 Jan 2016 21:09:31 +0100 [thread overview]
Message-ID: <56A923FB.4050308@drmicha.warpmail.net> (raw)
In-Reply-To: <xmqqmvrq99mt.fsf@gitster.mtv.corp.google.com>
Junio C Hamano venit, vidit, dixit 27.01.2016 19:10:
> 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.
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@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.
"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
next prev parent reply other threads:[~2016-01-27 20:09 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-25 21:22 [RFC] tag-ref and tag object binding Santiago Torres
2016-01-26 9:35 ` Michael J Gruber
2016-01-26 15:29 ` Santiago Torres
2016-01-26 20:26 ` Jeff King
2016-01-26 21:13 ` Junio C Hamano
2016-01-28 21:09 ` Santiago Torres
2016-01-26 21:44 ` Santiago Torres
2016-01-26 22:44 ` Junio C Hamano
2016-01-27 7:23 ` Michael J Gruber
2016-01-27 7:33 ` Jeff King
2016-01-27 7:53 ` Michael J Gruber
2016-01-27 8:09 ` Jeff King
2016-01-27 9:14 ` Michael J Gruber
2016-01-27 18:10 ` Junio C Hamano
2016-01-27 20:09 ` Michael J Gruber [this message]
2016-01-27 20:21 ` Jeff King
2016-01-28 21:06 ` Santiago Torres
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56A923FB.4050308@drmicha.warpmail.net \
--to=git@drmicha$(echo .)warpmail.net \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=peff@peff$(echo .)net \
--cc=santiago@nyu$(echo .)edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox