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

From: Santiago Torres <santiago@nyu.edu>
Date: Jan 26, 2016, 15:29 UTC
Message-ID: <20160126152941.GA31951@LykOS>
In-Reply-To: <56A73DE6.5050201@drmicha.warpmail.net>

On Tue, Jan 26, 2016 at 10:35:34AM +0100, Michael J Gruber wrote:

Show 34 quoted lines

> Santiago Torres venit, vidit, dixit 25.01.2016 22:22:
> > 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.
> 
> 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.

> 
> In fact, just like you shouldn't blindly download and install a tarball
> (but check its signature) you shouldn't blindly pull and install from a
> repo.

Yep. As a matter of fact, many of these package managers can install from a specific commit, which should be safer. However, I do think that pointing to a tag is more "usable" given that they are human-readable. Also, tags are usually meant to point to releases, so it follows its design pattern doesn't it?. I think it wouldn't be a bad idea to provide a hard-binding between tag-refs and tags themselves.

Show 6 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?

Thanks, -Santiago.