Git release tagging best practices

[James Bottomley]

On Fri, 2019-03-22 at 11:37 +0100, Peter Lebbing wrote:
> On 21/03/2019 22:50, James Bottomley wrote:
> > 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.
> 
> The third line of the signed data in the real-life example I
> demonstrated reads "tag gnupg-2.2.13". That very much looks like the
> name of the tag to me! Did you overlook it or do you think it's
> something else?

Ah, actually, I hadn't noticed that was in there.

> > 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.
> 
> But Git could check that the name of the file in .git/refs/tags
> matches the name in the signed data.

So that's related to use case, see below.

> > 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'd rather say "a use case" than "the use case", but okay.

The point is it's the use case signed tags were designed for.  It's
what all the cryptographic validation thought around signed tags went
into.

> It could easily support both. I don't recognise the use case you
> describe, but I presume when you say "there is no name", that the tag
> is used through its object hash. Git could skip verifying the name
> when the tag is specified through its object hash rather than its
> name.

When you do git pull remote-tree remote-tag

Git will validate the remote-tag cryptographically and its attachment
point but, because the tag will be discarded after the merge, it
doesn't validate the remote-tag matches the tag name.  It's how Linus
ensures cryptographically that what he pulls is what I pushed.

in this workflow the references file is on the remote tree, and the tag
won't become part of the local tree.  You could validate that remote-
tag, which will be taken from the remote tree references, matches the
tag name in the signed object but it has no value because the signed
part of the tag is merged into the commit object wholesale, so the
signature can still be verified, but the actual tag itself doesn't
become part of the local tree and is effectively discarded.

You can see this if you do a git log <sha> on a merge pull in the
kernel vs a git cat-file commit <sha>.

>   And if this is not what you meant, Git could gain a command line
> option to have it enforce the name is original, or an option to
> indicate the name should not be verified.

OK, but verify for what?  git-log <tag> probably.  git-archive <tag>
definitely but you need to identify the other commands and use cases. 
Cryptographic verification of every tag on all operations would be way
too expensive.

James


> Discarding is not a problem.
> 
> Cheers,
> 
> Peter.
> 
-------------- 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/20190322/be8fae56/attachment.sig>