Python – Installation from source fails because GnuPG cannot import keys without user ID

[hoechenberger]

Update & tl;dr
I figured our company firewall blocks connections to the default hkp port. The only hkps keyserver (to which connections are not blocked) specified in install.sh strips user IDs of some keys. GnuPG then refuses to import those keys. A solution could be to access the Ubuntu keyserver via hkp through port 80, which is not blocked. See my last comment: #717 (comment)

Original post
Installation of the python feature from source fails:

• At least one of the specified key servers doesn't report the user ID for five of the requested keys,
• hence GnuPG refuses to import those keys:

 => => # (*) Downloading GPG key...                                            
 => => # gpg: key 3A5CA953F73C700D: new key but contains no user ID - skipped  
 => => # gpg: key 04C367C218ADD4FF: new key but contains no user ID - skipped  
 => => # gpg: key 0EDDC5F26A45C816: new key but contains no user ID - skipped  
 => => # gpg: key 6AF053F07D9DC8D2: new key but contains no user ID - skipped  
 => => # gpg: key C9BE28DEE6DF025C: new key but contains no user ID - skipped  

devcontainer.json:

{
  "name": "dev",
  "image": "mcr.microsoft.com/devcontainers/base:debian-11",
  "features": {
    "ghcr.io/devcontainers/features/python:1": {
      "version": "3.11",
    },
  },
}

I can manually reproduce the problem on that container:

vscode ➜ ~ $ gpg --keyserver "hkps://keys.openpgp.org" --recv-keys 0x3A5CA953F73C700D
gpg: key 3A5CA953F73C700D: new key but contains no user ID - skipped
gpg: Total number processed: 1
gpg:           w/o user IDs: 1

GnuPG version:

vscode ➜ ~ $ gpg --version
gpg (GnuPG) 2.2.27
libgcrypt 1.8.8
Copyright (C) 2021 Free Software Foundation, Inc.
License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/vscode/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

Any help would be greatly appreciated.

[hoechenberger]

I figure this is related to this issue stated in the keys.openpgp.org FAQs. However, Debian's GnuPG is patched to allow updating of keys that have no user ID on the key server. I believe the issue here is that this patch fixes things only for updating locally existing keys. Hence, an initial import still doesn't work for me, even with the patched GnuPG.

I assume a solution could be to vendor the respective public keys, import them, and only then call gpg --recv-keys to update them. Then, things should work as expected.

[hoechenberger]

I also discovered that connections to hkp://keyserver.ubuntu.com always fail from my machine (I don't know why; I'm behind a corporate firewall), hence the openpgp.org keyserver is tried next, which strips the user IDs.

Changing hkp://keyserver.ubuntu.com to hkps://... allows me to retrieve the keys from that server.

Is there a specific reason you're going for hkp instead of hkps for this server in install.sh?

[hoechenberger]

So it appears our company firewall currently blocks port 11371, hence hkp connections fail, but hkps connections (which use port 443) do work.

Since the only keyserver in install.sh that is specified to use hkps is keys.openpgp.org, my container can only connect to this one. But it's also the very keyserver that strips user IDs of some keys; hence, key import fails.

I found out that keyserver.ubuntu.com can also be reached via port 80, specifically to make life easier for folks in a situation like mine. Hence, a very simple fix could be to change:

features/src/python/install.sh

Line 31 in 4fca96b

GPG_KEY_SERVERS="keyserver hkp://keyserver.ubuntu.com

to

GPG_KEY_SERVERS="keyserver hkp://keyserver.ubuntu.com:80

Would you be willing to accept a PR for this change?

[samruddhikhandale]

Hi 👋

Thanks for opening the issue, left a PR review. See #719 (review)

[Clockwork-Muse]

I swear, it worked yesterday.

Hitting this issue today. I am not on a corporate network, so not clear why it's failing.
error.log
devcontainer.zip

[Clockwork-Muse]

As a side note - Unfortunately due to one of the tools I need in my actual deployment being old, I currently need to use 3.9....

[Clockwork-Muse]

:sigh:
Never mind, transient issue, likely due to a cached base image. Dropping all the containers and rebuilding resolved it.