git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Santiago Torres <santiago@nyu.edu>
To: Git <git@vger.kernel.org>
Subject: [RFC] tag-ref and tag object binding
Date: Mon, 25 Jan 2016 16:22:09 -0500	[thread overview]
Message-ID: <20160125212208.GB26169@LykOS> (raw)

Hello everyone.

I've done some further research on the security properties of git
metadata and I think I've identified something that might be worth
discussing. In this case, The issue is related to the refs that point to
git tag objects. Specifically, the "loose" nature of tag refs might
possibly trick people into installing the wrong revision (version?) of a
file.

To elaborate, the ref of a tag object can be moved around in the same
way a branch can be moved around (either manually or by using git
commands). If someone with write access can modify where this ref points
to, and points it to another valid tag (e.g., an older, vulnerable
version), then many tools that work under the assumption of static tags
might mistakenly install/pull the wrong reivision of source code. I've
verified that this is possible to pull off in package managers such as
PIP, rubygems, gradle(maven), as well as git submodules tracking tags.

In order to stay loyal to the way files in the .git directory are
ordered, I don't think that making the ref file (or packed refs) files
differently is an option. However, I think that it could be possible to
store the "origin ref" in the git tag object, so tools can verify that
they are looking at the appropriate tag. There might also be a simpler
solution to this, and I would appreciate any feedback.

What do you guys think?

Thanks!
Santiago.

             reply	other threads:[~2016-01-25 21:22 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-25 21:22 Santiago Torres [this message]
2016-01-26  9:35 ` [RFC] tag-ref and tag object binding 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
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=20160125212208.GB26169@LykOS \
    --to=santiago@nyu.edu \
    --cc=git@vger.kernel.org \
    /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).