Re: Signing git tags for releases

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Sun, 26 Dec 2021 13:33:03 -0800
> Cc: larsi@gnus.org, emacs-devel@gnu.org
> 
> >> +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.

I'd prefer something that started with a command whose output shows
that key, which would then prompt the user to fetch the key.

> >> -     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.

I suggest to say that, something like

  GnuPG may ask for the key password.

> > 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.

Isn't that just a few commands?  We don't need to explain anything,
just to give a cookbook-stile list of instructions to follow.

> For simplicity and convenience, I think it is better if we try to ensure
> that only one person is signing things per release.

That doesn't work when that person steps down and someone else steps
up to the job.  Which is more or less the only situation where those
instructions are really important.

So any clarifications and cookbook-style instructions are bonus, I
think.

Thanks.