git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Michael J Gruber <git@drmicha.warpmail.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 02:33:58 -0500	[thread overview]
Message-ID: <20160127073357.GA7066@sigill.intra.peff.net> (raw)
In-Reply-To: <56A87056.2010309@drmicha.warpmail.net>

On Wed, Jan 27, 2016 at 08:23:02AM +0100, Michael J Gruber wrote:

> > Tag objects already have a "tag" header, which is part of the signed
> > content. If you use "git verify-tag -v", you can check both that the
> > signature is valid and that the tag is the one you are expecting.
> 
> Yes, that's what I described in my last paragraph, using the term
> (embedded) tag "name" which is technically wrong (it's not the tag
> object's name, which would be a sha1) but the natural term for users.

Indeed. I should have read further back in the quoting. :)

> > Git pretty much punts on all of these issues and assumes either a human
> > or a smarter tool is looking at the verification output. But I don't
> > think it would hurt to build in some features to let git automatically
> > check some things, if only to avoid callers duplicating work to
> > implement the checks themselves.
> 
> That is really a can of worms for several reasons:
> [...]
> So, for those who shy away from for-each-ref and such, we may add the
> header check to verify-tag, with a big warning about the marginal gain
> in security (or the requirements for an actual gain).

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.

-Peff

  reply	other threads:[~2016-01-27  7:34 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 [this message]
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
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=20160127073357.GA7066@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@drmicha.warpmail.net \
    --cc=git@vger.kernel.org \
    --cc=santiago@nyu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).