On Tue, Jan 26, 2016 at 10:35:34AM +0100, Michael J Gruber wrote: > 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. > > 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html