Today's Python 3.10.14 source release signed by wrong GPG key

[edmorley]

Bug description:

Several Python patch releases were released today:
https://blog.python.org/2024/03/python-31014-3919-and-3819-is-now.html

Attempting to build those with our existing automation is failing for the 3.10.14 release (only), seemingly due to the release having been signed with a different GPG key from normal:

+ curl --fail --retry 3 --retry-connrefused --connect-timeout 10 --max-time 60 -o python.tgz https://www.python.org/ftp/python/3.10.14/Python-3.10.14.tgz
 % Total % Received % Xferd Average Speed Time Time Time Current
 Dload Upload Total Spent Left Speed

 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
 0 24.7M 0 8427 0 0 7357 0 0:58:44 0:00:01 0:58:43 7359
100 24.7M 100 24.7M 0 0 14.7M 0 0:00:01 0:00:01 --:--:-- 14.7M
+ curl --fail --retry 3 --retry-connrefused --connect-timeout 10 --max-time 60 -o python.tgz.asc https://www.python.org/ftp/python/3.10.14/Python-3.10.14.tgz.asc
 % Total % Received % Xferd Average Speed Time Time Time Current
 Dload Upload Total Spent Left Speed

 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 833 100 833 0 0 3495 0 --:--:-- --:--:-- --:--:-- 3485
+ gpg --batch --verbose --recv-keys A035C8C19219BA821ECEA86B64E628F8D684696D
gpg: directory '/root/.gnupg' created
gpg: keybox '/root/.gnupg/pubring.kbx' created
gpg: no running Dirmngr - starting '/usr/bin/dirmngr'
gpg: waiting for the dirmngr to come up ... (5s)
gpg: connection to dirmngr established
gpg: data source: [https://keys.openpgp.org:443](https://keys.openpgp.org/)
gpg: pub rsa4096/64E628F8D684696D 2018-03-30 Pablo Galindo Salgado <EMAIL REDACTED>
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: using pgp trust model
gpg: key 64E628F8D684696D: public key "Pablo Galindo Salgado <EMAIL REDACTED>" imported
gpg: no running gpg-agent - starting '/usr/bin/gpg-agent'
gpg: waiting for the agent to come up ... (5s)
gpg: connection to agent established
gpg: Total number processed: 1
gpg: imported: 1
+ gpg --batch --verify python.tgz.asc python.tgz
gpg: Signature made Tue Mar 19 23:31:41 2024 UTC
gpg: using RSA key E3FF2839C048B25C084DEBE9B26995E310250568
gpg: Can't check signature: No public key

(see https://github.com/heroku/heroku-buildpack-python/actions/runs/8352048284/job/22861497406#step:4:47)

The old A035C8C19219BA821ECEA86B64E628F8D684696D key is still the one listed on:
https://www.python.org/downloads/

And there is no mention of a GPG key change in https://blog.python.org/2024/03/python-31014-3919-and-3819-is-now.html - and in fact the announcement suggests the signing part was meant to be unchanged:

The artifacts are later still signed by the respective release manager, ensuring integrity when put on the downloads server.

Is this a regression from the migration to releasing from GitHub Actions (mentioned in the blog post)?

cc @pablogsal

CPython versions tested on:

3.10

Operating systems tested on:

Linux

[edmorley]

Ah I guess the E3FF2839C048B25C084DEBE9B26995E310250568 key is Łukasz's key, which is normally used for Python 3.8/3.9 releases only?

If this is an intentional change, could (a) it be documented in the release blog post, (b) the "OpenPGP Public Keys" section of https://www.python.org/downloads/ be updated to remove the references to a specific person signing certain Python versions, and instead that any key could be used to sign any release?

[ned-deily]

Yes, the 3.10.14 release was manufactured this time by @ambv, rather than @pablogsal, and using an updated release process so, unfortunately, something like this could slip through.

[ned-deily]

P.S. Thanks for reporting it, @edmorley!

[edmorley]

Is the plan to re-sign using the normal key and overwrite https://www.python.org/ftp/python/3.10.14/Python-3.10.14.tgz.asc with the updated signature? Or to perform a new release?

[ned-deily]

Is the plan to re-sign using the normal key and overwrite https://www.python.org/ftp/python/3.10.14/Python-3.10.14.tgz.asc with the updated signature?

At the moment, the plan is to just re-sign the release artifacts with the usual RM key. That should happen in the near future.

[hugovk]

3.10 RM Pablo has re-signed the artifacts and updated the release so all should be as expected now. 🚀