Re: git tag -v should verify that the tag signer intended the same tag name as the user is verifying

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Wed, Mar 20 2019, Daniel Kahn Gillmor wrote:

> Hi git folks--
>
> I understand that git tags can be easily renamed.  for example:
>
>     git tag push origin refs/tags/v0.0.3:refs/tags/v2.3.4
>
> However, for tags signed with any recent version of git, the tag name is
> also included in the signed material:
>
>     0 dkg@test:~$ git tag -v v0.0.3
>     object 8ae6a246bef5b5eb0684e9fc1c933a4f8441dadd
>     type commit
>     tag v0.0.3
>     tagger Daniel Kahn Gillmor <dkg@fifthhorseman.net> 1528706225 +0200
>
>     this is my tag message
>     gpg: Signature made Mon 11 Jun 2018 04:37:05 AM EDT
>     gpg:                using Ed25519 key C90E6D36200A1B922A1509E77618196529AE5FF8
>     gpg: Good signature from "Daniel Kahn Gillmor <dkg@fifthhorseman.net>" [ultimate]
>     Primary key fingerprint: C4BC 2DDB 38CC E964 85EB  E9C2 F206 9117 9038 E5C6
>     0 dkg@test:~$
>
> But git tag doesn't verify that the internal name is the same as the
> external name (note that it still returns an exit code of zero):
>
>     0 dkg@test:~$ git tag -v v2.3.4
>     object 8ae6a246bef5b5eb0684e9fc1c933a4f8441dadd
>     type commit
>     tag v0.0.3
>     tagger Daniel Kahn Gillmor <dkg@fifthhorseman.net> 1528706225 +0200
>
>     this is my tag message
>     gpg: Signature made Mon 11 Jun 2018 04:37:05 AM EDT
>     gpg:                using Ed25519 key C90E6D36200A1B922A1509E77618196529AE5FF8
>     gpg: Good signature from "Daniel Kahn Gillmor <dkg@fifthhorseman.net>" [ultimate]
>     Primary key fingerprint: C4BC 2DDB 38CC E964 85EB  E9C2 F206 9117 9038 E5C6
>     0 dkg@test:~$

I'm sympathetic to the whole problem, but don't have anything to add to
t he thread Santiago linked to. Except...

> This seems troublesome, as I expect there are many scripts that rely on
> the tag name and the return code of "git tag -v" to assert that this is
> a correct tag.  Anyone in control of the above repository could pass off
> an old tag (or indeed, a tag from an entirely different project that
> happens to be signed by the same author) as whatever version they wanted
> to, and convince automated scripts that work with new versions to
> "upgrade".
>
> I think "git tag -v" should be more strict about what it needs to "pass"
> a verification.

... just a point of clarification on the "a tag from an entirely
different project" part of this.

Maybe I'm missing something, but it doesn't seem like your proposed
solution helps much with *that* threat model as you've described it.

If all I'm doing is blindly slurping down one out of a bunch of
repositories you commit to and tag releases in, sorting the tags, and
getting the latest one you (dkg@fifthhorseman.net) signed, I'm still
mostly open to this problem.

The only thing that'll change is that you can't fool me if I'm looking
at whatever project you happen to contribute to that has the highest tag
version across *all* projects you contribute to.

But e.g. if you've signed a v1.00 in foo.git, but also maintain bar.git
and have a v2.00 there, I can be fooled in foo.git with your proposed
change by having the v2.00 bar.git tag pushed to it (just, with the
proposed change, not the other way around).

It *does* help with the "pass of an old tag [from the same repository]"
problem, which I'd expect would realistically be the only threat model
that matters (forcing a downgrade to an old buggy version), whereas some
entirely different project is likely going to be next fed to some
project-specific build infrastructure and then won't even build.

*but*

I wonder if there's a more general fix to be found here that'll have
nothing to do with GPG or signed tags per-se. A lot of people have this
"given tags in the repo, what's the latest one?" problem. I think
they'll mostly use the --sort option now, maybe some variant of that
which for each <older>/<newer> tag in the chain also checked:

    git merge-base --is-ancestor <older> <newer>

That would serve as a check for such rouge tags, even if none of them
were signed, and a "they must be signed" option could be added, along
with "start walking from here".

It wouldn't help with cases where you legitimately *do* want to re-tag
an old version (for a revert), but in some cases tagging always moves
forward in history (always newer commits).

Just food for thought...