From: Michael J Gruber <git@drmicha•warpmail.net>
To: Jeff King <peff@peff•net>
Cc: Santiago Torres <santiago@nyu•edu>, Git <git@vger•kernel.org>
Subject: Re: [RFC] tag-ref and tag object binding
Date: Wed, 27 Jan 2016 10:14:17 +0100 [thread overview]
Message-ID: <56A88A69.6030503@drmicha.warpmail.net> (raw)
In-Reply-To: <20160127080901.GA7651@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 27.01.2016 09:09:
> On Wed, Jan 27, 2016 at 08:53:08AM +0100, Michael J Gruber wrote:
>
>>> Yeah, definitely. My thinking was that `verify-tag` could learn a series
>>> of optional consistency checks, enabled by command line options, and
>>> verifying programs (or humans) could turn them on to avoid having to
>>> replicate them manually. So something like:
>>>
>>> git verify-tag \
>>> --verify-tagger-matches-key \
>>> --verify-tag-matches-ref \ # or --verify-tag-matches=v2.0.0
>>> v2.0.0
>>>
>>> or to implement more specific policy, maybe an option to check for a
>>> _specific_ tagger, either by email (as provided by gpg) or even key-id.
>>>
>>> Those are all things that are not _too_ hard to do if you're willing to
>>> parse gpg or git output, but we could make life easier for our callers.
>>> And hopefully by asking for specific, concrete checks, it doesn't
>>> introduce a false sense of security. I.e., we're not making a foolproof
>>> tool; we're making building blocks that one could use for a more
>>> foolproof tool.
>>
>> OK, let's make a tool that helps fooling as well as proofing :)
>>
>> I'll look into the tag header check. Maybe "--check-tagname"? "check"
>> seems to imply less than "verify".
>
> Yeah, I think that is fine (I actually wrote --check originally; I'm not
> quite sure why I decided to change it).
>
>> As for the gpg related stuff: We provide the full diagnostic output from
>> gpg on request. But I think a mismatch between the signing key's uid and
>> the taggers' name/email is more common than not,
>
> Is it? I'd think if you are using that name with a signed tag, you would
> bother to issue (and get people to sign) the matching uid. Certainly it
> is the case for git and linux signatures, but I admit that it a pretty
> small sampling size.
>
> 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.
uids do not identify keys, you can add and delete them at will without
changing the primary key id. To help recognize ("identify") a key, gpg
displays the uid with the most recent self-signature, which is usually
the most "recent uid".
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.
>> and on the other hand a
>> signature by a key identified by its uid is meaningless unless you keep
>> your keyring tidy... We could punt on that and let users identify the
>> key by any means that gpg allows, of course, and check that the
>> signature comes from whatever "gpg --list-key <userspecified>" gives as
>> long as it's unique.
>
> Right, I think it's an open question whether people actually participate
> in the web of trust. I don't have a good signature path to Junio's key,
> but I happen to know what it is based on past interaction.
>
> But then, I also do not really verify tags. Why would I? I routinely
> fetch and run "make" on the result, and there is no cryptographic
> protection there at all. Verifying tag signatures after a release seems
> all but pointless. :)
No signature protects us from our own dogfood :)
> I think for any of this to be useful, it has to be part of some tool
> that is very opinionated on policy. E.g., imagine a post-fetch hook that
> validated that each incoming commit was signed, and that the signer was
> part of a whitelisted group of keys that you "somehow" got hold of
> out-of-band for your project. That is not that useful for an open-source
> project, but I could see the appeal for a proprietary development
> environment.
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).
Michael
next prev parent reply other threads:[~2016-01-27 9:14 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 [this message]
2016-01-27 18:10 ` Junio C Hamano
2016-01-27 20:09 ` Michael J Gruber
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=56A88A69.6030503@drmicha.warpmail.net \
--to=git@drmicha$(echo .)warpmail.net \
--cc=git@vger$(echo .)kernel.org \
--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