Git release tagging best practices

[Daniel Kahn Gillmor]

Hi GnuPG folks--

I was just reviewing the cryptographically-signed git tags that
represent releases of GnuPG, thanks to the 2.2.14 release, which i'm
aiming to upload into debian experimental later today.  I enjoy the
commentary and media recommendations included in the git tag messages,
but i think they aren't currently very useful for downstream verifiers.

I recommend making a standardized message for each future release tag,
starting with a single line "GnuPG version $version".  This allows any
downstream to defend against a possible obscure attack against any other
repositories of software that you might also sign.  (and it would defend
GnuPG against impersonation attacks from any other such project as well)

So, rather than doing:

    git tag -s -m 'Just another boring release' gnupg-2.2.15

Instead, please do:

    git tag -s -m 'GnuPG version 2.2.15' gnupg-2.2.15

The issue is that the thing that is being tagged is not clearly
recognizable as GnuPG -- it's just something signed, by OpenPGP
certificate 0xD8692123C4065DEA5E0F3AB5249B39D24F25E3B6.  People might
evaluate it as a a GnuPG release because of where they happen to find
the git repository (e.g. the URL they chose), but the same git
repository can be replicated to some other location, and the signed tag
will show up there as well.

By ensuring that your git tag messages are specific to the project that
you're signing, and that they include the release information that you
are trying to convey, someone verifying your signed tag on *any*
repository can defend against this attack by ensuring not only your
signature, but also that the signing message is related to the project
that they care about.

If you want to include reading recommendations and other interesting
commentary, you can still do that by adding additional -m options (git
will concatenate them with blank lines between).  As long as you reserve
the first line as a standardized and unambiguous form, then that gives
automated downstream checks something to concretely verify, rather than
having them guess that this is actually the right new tag, based on
non-verifiable features like tag name, repository location, etc.

I'm recommending these as best practices, while acknowledging that very
few projects follow them yet.  I'm hoping that GnuPG can help to lead
the way in establishing this sort of convention, so that i can encourage
downstream tools to verify meaningful signatures, rather than just
"something that Werner or gniibe signed".

All the best,

          --dkg

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190319/24951379/attachment-0001.sig>