Git release tagging best practices

[James Bottomley]

On Wed, 2019-03-20 at 08:28 -0400, Daniel Kahn Gillmor wrote:
> On Tue 2019-03-19 19:09:25 +0100, Peter Lebbing wrote:
> > On 19/03/2019 17:32, Daniel Kahn Gillmor wrote:
> > > PS Note that the *name* of the tag itself is not covered by the
> > >    cryptographic signature (it is possible to rename tags without
> > >    modifying their cryptographic validity).  This is why I
> > > recommend
> > >    using the tag message to contain this information rather than
> > > the tag
> > >    name itself.
> > 
> > Are you sure? I looked at what the exact data that is signed is,
> > and it seems to me it does include the name:

It can't.  Remember the name of the tag is metadata which is held in
the git refs file not in the tag itself.  The signature of the tag is
over the contents (including header contents like date and parent)
which doesn't include the name.

This means the name of the tag can be changed by changing the refs file
and actually you can erase the tag with no adverse consequences to the
tree.  What you can't do is move it to a different parent because that
will cause a verification failure.

> That's interesting, thanks for pointing it out.  There are two places
> for the name of the tag, and i think you're right that the signatures
> made by modern git tags do seem to include the tag name (gnupg is
> ahead of the game here, fwiw: many projects don't include the project
> name in their tag name, and just go with tags like v2.2.13, which
> leave the same issue open).  I didn't think that they used to do
> that, but maybe they did and i just never noticed.
> 
> > Note that the third line of the signed data reads "tag gnupg-
> > 2.2.13". So is there some loophole that means this is not useful?
> 
> To test that, i've just pushed https://gitlab.com/dkg/renaming-
> demo.git, where I've just re-named a different tag issued by Werner.
> 
> If you were to clone that repository, you'll note that "git tag -v
> gnupg-2.2.13" returns success, even though the contents of the
> message don't say "tag gnupg-2.2.13".  
> 
> So i suppose it depends on how you think people are verifying that
> tag. I'd imagine most folks (if they verify the tag at all) just
> check that git tag -v $tagname returns 0 (and maybe they check that
> the tag was made by a key that they associate with the project).
> 
> I wonder whether we "git tag -v" should raise an error if the tag
> name within the signature doesn't match the tag name being verified.

Absolutely not, at least not globally.  Remember the design use case
for signed tags is cryptographically verified pull requests, in which
case there is no name and the tag is discarded after the pull.

>   I've just sent message-id: <875zsdu41d.fsf at fifthhorseman.net> to gi
> t at vger.kernel.org to ask about improving the situation there (maybe i
> need to subscribe to convince them to let my mail through, though, i
> don't know).

What you might ask for, if the project locally wanted to add the tag to
the commit and verify it was present, is the same pre- post- -msg hooks
we have for a commit which would allow you to customize on a per-
project basis.

James


> > I'm not saying that the first line of tag messages shouldn't be
> > standardized as you propose, I'm just debating the correctness of
> > the
> > quoted assertion.
> 
> Thanks for the clarifying question, and for pointing this out!
> 
> Regards,
> 
>         --dkg
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190321/62d1c2b0/attachment.sig>