git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Santiago Torres <santiago@nyu.edu>
Cc: Michael J Gruber <git@drmicha.warpmail.net>, Git <git@vger.kernel.org>
Subject: Re: [RFC] tag-ref and tag object binding
Date: Tue, 26 Jan 2016 15:26:51 -0500	[thread overview]
Message-ID: <20160126202651.GA1090@sigill.intra.peff.net> (raw)
In-Reply-To: <20160126152941.GA31951@LykOS>

On Tue, Jan 26, 2016 at 10:29:42AM -0500, Santiago Torres wrote:

> > If you cannot trust those with write access to a repo that you are
> > pulling and installing from you might want to re-check where you are
> > pulling or installing from ;)
> 
> Yeah, I see your point, but mechanisms to ensure the server's origin can
> be bypassed (e.g., a MITM). I don't think it would hurt to ensure the
> source pointed to is the source itself. The tag signature can help us do
> this.

Right. I think the more interesting use case here is "I trust the
upstream repository owner, but I do not trust their hosting site of
choice."

> > Your best bet is checking the signature of signed tags. Now, if you're
> > worried about someone maliciously pointing you to the wrong, correctly
> > signed tag then you should verify that the tag object contains the tag
> > "name" that you expect (for example by using "git verify-tag -v" or "git
> > cat-file -p"), since that is part of the signed content.
> 
> Yep, this is my intuition behind my proposal. While someone can manually
> inspect a tag (git tag -v [ref]) to ensure he's getting the correct one,
> there's no mechanism to ensure that the ref is pointing to the intended
> tag. I do believe that package managers and git submodules could check
> whether the ref is pointing to the right tag with a small change in the
> tag header. Although it would be up to each tool to implement this
> check.
> 
> I don't think that an addition like this would get in the way of any
> existing git workflow, and should be backwards-compatible right?

Doesn't this already exist?

  $ git cat-file tag v2.0.0
  object e156455ea49124c140a67623f22a393db62d5d98
  type commit
  tag v2.0.0
  tagger Junio C Hamano <gitster@pobox.com> 1401300269 -0700

  Git 2.0
  -----BEGIN PGP SIGNATURE-----
  [...]
  -----END PGP SIGNATURE-----

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.

Of course, "verify-tag" could do this for you if you give it a refname,
too, but I think that may be the tip of the iceberg in terms of
automatic verification. In particular, verify-tag knows it was signed by
_somebody_, but it doesn't know what the signing policy is. As a human,
_I_ know that Junio is the right person to be signing the release tag,
but no tool does.

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.

-Peff

  reply	other threads:[~2016-01-26 20:26 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 [this message]
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
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=20160126202651.GA1090@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).