On Sun, Aug 31, 2014 at 03:46:42PM -0700, Junio C Hamano wrote: > If "git fsck" were a tool to validate that the objects and refs are > in line with how "git-core" plumbing and Porcelain toolset uses the > underlying Git data model, it makes sense to insist a tag has a name > that is suitable for a refname, and the tag is pointed by a ref in > "refs/tags/" followed by its name. The rules such a "git fsck" should > implement would be stricter than what the underlying Git data model > could represent and existing Git tools could handle (i.e. a commit > with broken ident line may not be usable with "shortlog -e" and would > be flagged as corrupt).
This is a bit of an aside, but why do we have the "tag" line in the tag object in the first place? It is part of the object contents, and therefore is part of the signature (which the refname is not). That's somewhat redundant with the tag message itself. E.g., the git v2.0.4 tag says: object 32f56600bb6ac6fc57183e79d2c1515dfa56672f type commit tag v2.0.4 tagger Junio C Hamano <gits...@pobox.com> 1406755201 -0700 Git 2.0.4 -----BEGIN PGP SIGNATURE----- ... Imagine an evil person pushed the signed v2.0.4 tag to refs/tags/v2.1.0 (perhaps because there is a bug in v2.0.4, and they want you to run the wrong version so they can exploit it). You can check with "git show" that the "tag" field is actually v2.0.4, but then you could similarly check that the message says "Git 2.0.4". The main advantage of the "tag" field is that it is machine-readable, and that your verification process can check that "git verify-tag v2.1.0" actually returns a tag that says "tag v2.1.0". But I do not think we do that verification at all. I wonder if that is something we should add support for. You gave examples later in your email of tags that would not necessarily care about this tag field (and anyway, if "for-linus" is used over and over, it is subject to these sorts of replays), so I do not think it is something we would want unconditionally in verify-tag. I think this may need to be filed under "possible policy flags for verifying" that we discussed earlier (i.e., in the same boat as "does the committer ident match the commit signature", as it is a porcelain-ish policy, not an integral part of the plumbing). So this is mostly food for thought at this point. -Peff -- 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
