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

From: Santiago Torres Arias <santiago@nyu.edu>
Date: Mar 20, 2019, 14:20 UTC
Message-ID: <20190320142055.zlh5iby5pxs3fy3r@LykOS.localdomain>
In-Reply-To: <875zsdu41d.fsf@fifthhorseman.net>

Hi,

This has been known for a whlie now[1]. The consensus back then was that this information was up to higher-level integrators to verify using means like e.g., --format.

This is implemented in for example pacman/devtools here[2]. We published a paper with a more thorough security model here[3], and there's some stalled work into implementing this using push certificates...

Thanks, -Santiago.

[1] https://public-inbox.org/git/xmqqk2hzldx8.fsf@gitster.mtv.corp.google.com/ [2] https://lists.archlinux.org/pipermail/pacman-dev/2017-September/022123.html [3] https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/torres-arias

On Wed, Mar 20, 2019 at 08:24:46AM -0400, Daniel Kahn Gillmor wrote:

Show 60 quoted lines

> 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:~$
> 
> 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.
> 
> At a minimum, if the internal tag name (the line matching "^tag " before
> the first blank line) doesn't match the tag name being verified, "git
> tag -v" should report a warning to stderr and return a non-zero error
> code.
> 
> What do you think?
> 
> i'm not subscribed to git@vger.kernel.org, so please keep me in Cc on
> this thread, thanks!
> 
>     --dkg