Latest 3.12.0 release does not have GPG signature

[ainola]

Hello! Thanks for your work on releasing 3.12.0! Unlike 3.11.x, 3.12.0 does not feature an .asc file with which to verify downloads. Could that be added for packagers, please? Thanks!

[dyfer]

Hello @ainola !
I've added the signature to the release page on github. Does it look correct?
Downloads page will get updated shortly with the link to the key.

[dvzrv]

@dyfer Thanks for also looking into the PGP signature for the source tarball.

Can you please upload the public key with the ID 2E1C4FC2F6BB58FA157B21B8064B501EB7405F04 to keyserver.ubuntu.com or keys.openpgp.org and/or add it to your github account? I can not retrieve it from any of these sources.

Also, does it feature a signature by @mossheim who has been signing the previous releases (this ensures an intact chain of trust from one developer to the next)?
If not, I'd kindly ask them to sign it (once the key can be retrieved).

[dvzrv]

Following up in a private conversation, it appears that the signature will not happen.
Unfortunately, this means that the chain of trust between the last and this release is broken. These things happen (people leave projects and not always things are handed over in time, etc.), but it would be great to guard against this situation in the future.

For some background information on the script that creates tarball and signature, please have a look at #4837

The PGP signature is created to provide downstream consumers with an assurance, that the release has been created by you (e.g. "the release manager").

In the case where there are multiple developers issuing releases and PGP signatures are issued for releases, the PGP keys should be cross-signed (e.g. the keys signed each other and the signatures are available on keyservers or on the individual's WKD).

Alternatively (or additionally) one may add a section to the README or a dedicated document, that states the expected developers who are responsible for creating releases and their respective PGP key IDs. In that case the first person (see TOFU) to sign releases (in this case @dyfer) would create that section, add themselves to it using a signed commit and only add additional entries using signed commits as well (people represented by additions to the document may then add/remove further themselves, etc.).
An example of how this may look like can be observed in qtile's README.

This way it is easy for downstreams to spot who is expected to craft releases for the project and to follow up on the chain of trust (e.g. either due to the document's history or the keys' signatures amongst one another).

[dyfer]

I've added my GPG public key to my github account. I believe this solves this issue.

I'd like to discuss changes to the README in a separate ticket.

Feel free to reopen if I'm missing anything!