On Tue, Jan 26, 2016 at 03:26:51PM -0500, Jeff King wrote: > 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."
Yes, I think this is another possible scenario. Thanks for pointing it out. > > > > 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 <gits...@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. Oh, I inspected the tag object with cat-file, but I assumed this was being inserted by the command itself (by "pretty printing"). This is exactly what I was thinking. > > 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. Yes, I think it could be a good first step though (maybe returning non-0 if the tag header could help in this case). If this header exists, I think that package managers (and git submodules) should use it to verify this metadata attacks don't take place; it sounds rather simple. > 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. Yes, shipping a keychain might be helpful, I know the folks at I2P[1] do that in their monotone repository. Maybe something similar could be an extension to git? (using hooks, possibly?) > > Git pretty much punts on all of these issues and assumes either a human > or a smarter tool is looking at the verification output. Yeah, I agree. This works pretty well in some workflows (e.g., the one in this very ML), but I have the feeling this is not the trend that newer users of the tool are adopting. > 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. Yeah, I think this check (and maybe others) could be quite simple to integrate and lessen the workload on the git user. Inspecting each git tag after recursively cloning might mitigate an attack like this, but it sounds burdensome. Thanks! -Santiago. [1] https://geti2p.net/en/get-involved/guides/monotone#setting-up-trust-evaluation-hooks -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
