Over at [multibuild](https://github.com/pypa/manylinux/pull/333#issuecomment-519802858), they ran into an issue trying to build c-extensions with the 3.8rc3 since it seems it is not gpg signed.

I could not find a HOWTO_RELEASE document to check that the release workflow includes signing the package. One exists in Tools/msi/README.txt.

The description of this issue is incorrect. All the release artifacts for the 3.8.0b3 have GPG signatures available - see https://www.python.org/downloads/release/python-380b3/ - like all other releases.  Looking at the log of the failed Travis run in https://github.com/pypa/manylinux/pull/333, the failure there appears to be not finding the release manager's public key to verify the GPG signature against.  There is a languishing open issue about the published public keys files having bogus keys in it (https://github.com/python/pythondotorg/issues/1395), perhaps that is related.  I'll take a close look shortly.

We are seeing the same issue with 3.8b4:

+ curl -fsSLO https://www.python.org/ftp/python/3.8.0/Python-3.8.0b4.tgz
+ curl -fsSLO https://www.python.org/ftp/python/3.8.0/Python-3.8.0b4.tgz.asc
+ gpg --verify Python-3.8.0b4.tgz.asc
gpg: Signature made Thu 29 Aug 2019 10:43:07 PM UTC using RSA key ID 10250568
gpg: Can't check signature: No public key



See https://github.com/pypa/manylinux/pull/344.

It looks like you don't have Łukasz key and your GnuPG is not configured for automatic key download.

Automatic key download works for me:

$ gpg --verify Python-3.8.0b4.tgz.asc 
gpg: assuming signed data in 'Python-3.8.0b4.tgz'
gpg: Signature made 2019-08-30T00:43:07 CEST
gpg:                using RSA key E3FF2839C048B25C084DEBE9B26995E310250568
gpg: requesting key 0xB26995E310250568 from hkp server keys.fedoraproject.org
gpg: key 0xB26995E310250568: public key "Łukasz Langa (GPG langa.pl) <lukasz@langa.pl>" imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg: Good signature from "Łukasz Langa (GPG langa.pl) <lukasz@langa.pl>" [undefined]
gpg:                 aka "Łukasz Langa <lukasz@python.org>" [unknown]
gpg:                 aka "Łukasz Langa (Work e-mail account) <ambv@fb.com>" [undefined]
gpg:                 aka "[jpeg image of size 24479]" [unknown]


You could also download the key from keybase:

$ gpg --fetch-keys "https://keybase.io/ambv/pgp_keys.asc?fingerprint=e3ff2839c048b25c084debe9b26995e310250568"
gpg: requesting key from 'https://keybase.io/ambv/pgp_keys.asc?fingerprint=e3ff2839c048b25c084debe9b26995e310250568'
gpg: key 0xB26995E310250568: "Łukasz Langa (GPG langa.pl) <lukasz@langa.pl>" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1

Is automatic download really the best solution?

This is GPG. You have to download and verify the signature somehow. That's how GPG works. You can either let GPG do it automatically or you can do it manually.

I am not a gpg expert, but I think the proper solution is to add the release manager's key to the official Python GPG public key list. What would it take for that to happen?

If you use pubkeys.txt from https://www.python.org/static/files/pubkeys.txt, then GPG verification gives you no additional security. An attack with write access to www.python.org or access to the private key of www.python.org can easily replace the pubkeys.txt with a key file under his control. You only get additional security if you retrieve the key from a different location *and* verify that the key owned by Łukasz.

> If you use pubkeys.txt from https://www.python.org/static/files/pubkeys.txt, then GPG verification gives you no additional security

I am confused. If the pubkeys.txt on python.org has no benefit, why does it exist? What is considered best practices for people wanting to verify the download from https://www.python.org/ftp ?

> If the pubkeys.txt on python.org has no benefit, why does it exist?

That's an excellent question!  Based on the points raised here and elsewhere, we discussed this more off-line and decided that we should remove the pubkeys.txt file from the website since, as noted here, it encourages a false sense of security and has proven difficult to keep up-to-date.

I have submitted a request to have the file removed from the website (it may take some time for the URL to disappear) and have already updated the wording in the OpenPGP section of the Downloads page of the website.  If anyone has suggestions for improvements to the wording, feel free to submit them on the pythondotorg issue tracker.

Thanks all for bringing this up and helping to come to a resolution.

https://www.python.org/downloads/
https://github.com/python/pythondotorg/pull/1509
https://github.com/python/pythondotorg/issues

The problem with not authoritatively publishing one or more public keys for the Python tarballs is that no one will know for sure which key to trust. If you naively download the public key associated with a malicious tarball, you would trust it w/o realizing that it's malicious (assuming that the tarball developers themselves have not gone rogue).

I strongly urge the Python developers to use at least one official GPG key to sign all tarballs, and publish that on its web site (perhaps indirectly using Keybase).

stage: resolved