Re: [PATCH 4/6] fsck: check tag objects' headers

[Jeff King <peff@peff.net>]

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 <gitster@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