Git release tagging best practices
peter at digitalbrains.com
Fri Mar 22 11:37:49 CET 2019
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
> 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.
> 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.
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. 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.
Discarding is not a problem.
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 488 bytes
Desc: OpenPGP digital signature
More information about the Gnupg-devel