Re: Signing git tags for releases

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> Some comments below.

Thanks.

>> +Recent tags are signed for additional security.  To verify a
>> +signature, type "git tag -v TAGNAME".  You will first need to fetch
>> +the public key used to sign the tag, using something like:
>> +
>> +  gpg --keyserver pgp.mit.edu --recv-keys \
>> +    CEA1DE21AB108493CC9C65742E82323B8F4353EE
>
> This should explain where did that long hex string come from, and how
> it is related to some particular signed tag.

How about adding:

    The last argument to the above command should be the id of the key
    used to sign the tag you want to verify.

>> -     cd EMACS_ROOT_DIR && git tag -a TAG -m "Emacs TAG"
>> +     cd EMACS_ROOT_DIR && git tag -s TAG -m "Emacs TAG"
>
> Won't Git then ask for some input?  IOW, does this describe the
> interaction completely enough for the person who does this the first
> time to know what to do?

This describes the full interaction, except for the password prompt.

> And what about the preparations, like making
> sure one has GnuPG, having a key available, etc.?  The first time I
> needed to upload an Emacs tarball (which also needs to be signed), I
> needed to read quite a lot on how to use GnuPG, how to generate a key,
> how to use it, etc.

Yeah, GnuPG is... a lot to wrap your head around.  That is unfortunately
the case whether we sign tags or not.

Documenting all the things you talk about sounds to me like a
significant effort, which risk duplicating tutorials and documentation
for gpg itself.  I suggest not doing that, not least because I don't
feel comfortable writing such a tutorial.  Though I won't object if
someone wants to write such a tutorial or perhaps better point out a
good existing one that we could refer to.

> And finally, is signing the tags a requirement?  Is it possible to
> commit an unsigned tag for pretest or release?

Nothing will technically stop us from doing that, but I think we might
as well make signing into a requirement.  The person doing the release
will need to have a gpg key in any case, so it is not more work.

>> +     git tag -s emacs-28.0.90  -m "Emacs 28.0.90 pretest"
>> +     git tag -s emacs-28.1-rc1 -m "Emacs 28.1 RC1"
>> +     git tag -s emacs-28.1     -m "Emacs 28.1 release"
>> +
>> +    The "-s" option above means to sign the tag using your default GPG
>> +    key.
>
> What if the person has more than one key?

No idea, but here's what "man git-tag" has to say:

       -s, --sign
           Make a GPG-signed tag, using the default e-mail address’s key. The
           default behavior of tag GPG-signing is controlled by tag.gpgSign
           configuration variable if it exists, or disabled otherwise. See
           git-config(1).

>>            Make sure this uses the same GPG key that you use to sign
>> +    the release (see below).
>
> This might not be possible, if the person who tags the release/pretest
> doesn't have an uploader key.  Also, the pointer to "below" may not be
> accurate enough, because "sign the release" as a phrase doesn't appear
> anywhere, and references to "key" are many enough to confuse.  This
> must be explained in the clearest terms, because people who are not
> used to sign stuff will be nervous and stressed when required to do
> this.

I can only agree about the nervous and stressed part.  The entire
release process is somewhat nerve-racking, and having to deal with gpg
doesn't make things any easier.

For simplicity and convenience, I think it is better if we try to ensure
that only one person is signing things per release.  It's probably okay
that someone else signs the release tag, but I'd hope that it's someone
who's already configured gpg and is at least somewhat familiar with the
release process.