gpg/dirmngr issues with keyserver.ubuntu.com
Sometime between build 3470 & 3604n gpg/dirmngr can no longer communicate with hkps://keyserver.ubuntu.com and is instead overriding it to hkps://pgpkeys.eu. hkp traffic works to ubuntu's keyserver, which leads me to believe it's related to https://github.com/GPGTools/MacGPG2/blob/dev/patches/gnupg/change-d...
I also tried this on build 3613n and then it could not contact ubuntu's keyserver using hkps OR hkp, throwing this error instead:
gpg: error searching keyserver: No route to host
gpg: keyserver search failed: No route to host
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
Support Staff 1 Posted by Steve on 19 Feb, 2026 09:41 PM
Hi gpg_dude,
thanks for taking the time to report this issue.
Using 3613n (EDITED) first I tried this in terminal:
which worked fine.
Then I tried setting hkps://keyserver.ubuntu.com as key server in GPG Keychain which also worked as expected and key searches were still possible.
Now the question is how your system differs from mine. I am still on macOS 15.7.4 but I can't image Tahoe chanced that much that it would interfere with gnupg in that it can't reach a key server entered by a user.
Could you try this via CLI with any email address that gives some known results and share the input and output.
Are you using any firewall software?
All the best,
Steve
2 Posted by gpg_dude on 19 Feb, 2026 10:01 PM
Hey Steve,
I don't think I have access to 3413n, but if the version numbers are always ascending I assume that version predates this issue which I show started sometime between versions 3470 & 3604n (and then again 3613n where the behavior changed again to not being able to return any results). I don't have any firewall software that would be blocking/manipulating the outbound traffic and am always able to access the keyservers via a web browser using the same SSL secured port, 443.
Support Staff 3 Posted by Steve on 19 Feb, 2026 10:05 PM
Sorry my bad: 3613n is the latest nightly and the one I was using in my tests.
Could you retry with that version? You did mention it in your initial report and can find it on https://releases.gpgtools.org/nightlies/
Could you temporarily use your mobile as hotspot and see if that changes anything?
4 Posted by gpg_dude on 20 Feb, 2026 12:34 AM
No worries. I re-tried using both nightly versions (3604n & 3613n) and also the last stable release (2023.3). I captured network traffic for each one showing the DNS requests being made followed by the request traffic. I did all of it in a fresh VM so nothing else possibly getting in the way (my main laptop has gnupg from homebrew too so it's possible that was occassionally getting in the way). Using just the package(s) from GPGTools I get the same behavior as before:
I'm attaching the tcpdump outputs for each permutation of version & protocol.
Support Staff 5 Posted by Steve on 24 Feb, 2026 07:02 PM
When trying to reproduce I set
hkps://keyserver.ubuntu.comas keyserver in GPG Keychain and had no trouble to execute key searches. That would deviate from your findings, correct?Would you be willing to temporarily remove the homebrew gpg version from your main laptop and then see if you are able to set and use hkps://keyserver.ubuntu.com in GPG Keychain?
6 Posted by gpg_dude on 24 Feb, 2026 07:57 PM
In my testing, key searches "work" but they are executed against pgpkeys.eu as the keyserver. I've tested this on multiple systems that only have GPGTools installed, so no homebrew or competing versions from other sources. I enabled dirmngr debug logging and can even see it note the keyserver change to ubuntu, but then the test query is issued against pgpkeys.eu as are subsequent operations that require a keyserver. Log attached.
Since you mentioned setting the server in GPG Keychain whereas I've been doing so using the CLI, I decided to make sure that wasn't why we are seeing different results In doing it this way, the behavior does not change and I also observed that it's impossible to set the keyserver to "hkp://keyserver.ubuntu.com" - GPG Keychain automatically changes it to "hkps://keyserver.ubuntu.com". This is not the case for other keyservers, which GPG Keychain allows me to set them using hkp:// and also properly queries them compared to re-routing me to pgpkeys.eu
Can you confirm whether or not the patch I mentioned in the OP (https://github.com/GPGTools/MacGPG2/blob/dev/patches/gnupg/change-d...) would explain this behavior? It seems like it would be a prime candidate given the all the data points I'm seeing related to this. Thanks.