git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Jeff King <peff@peff.net>
Date
Jan 26, 2016, 20:26 UTC
Message-ID
<20160126202651.GA1090@sigill.intra.peff.net>
In-Reply-To
<20160126152941.GA31951@LykOS>
On Tue, Jan 26, 2016 at 10:29:42AM -0500, Santiago Torres wrote:
Show 8 quoted lines
> > 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."

Show 16 quoted lines
> > 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
Previous: Santiago TorresNext: Junio C Hamano
Message 4 of 17 in “[RFC] tag-ref and tag object binding”
  1. Santiago TorresJan 25, 2016
  2. Michael J GruberJan 26, 2016
  3. Santiago TorresJan 26, 2016
  4. Jeff KingJan 26, 2016
  5. Junio C HamanoJan 26, 2016
  6. Santiago TorresJan 28, 2016
  7. Santiago TorresJan 26, 2016
  8. Junio C HamanoJan 26, 2016
  9. Michael J GruberJan 27, 2016
  10. Jeff KingJan 27, 2016
  11. Michael J GruberJan 27, 2016
  12. Jeff KingJan 27, 2016
  13. Michael J GruberJan 27, 2016
  14. Junio C HamanoJan 27, 2016
  15. Michael J GruberJan 27, 2016
  16. Jeff KingJan 27, 2016
  17. Santiago TorresJan 28, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.