gpg --recv-key often hangs due to unreliable keyserver
gpg --recv-key "2224 5C81 E3BA EB41 38B3 6061 310F 5612 00F4 AD77"
but it hangs and timesout.
Steps to Reproduce¶
- Install https://tails-dl.urown.net/tails/stable/tails-amd64-3.0/tails-amd64-3.0.iso with persistence and boot with an admin password.
- Connect to internet (via wifi, no firewall)
- Verify connectivity with sudo apt-get update
- Open a terminal
- $ cat /home/amnesia/.gnupg/dirmngr.conf
- gpg --debug-all --recv-key "2224 5C81 E3BA EB41 38B3 6061 310F 5612 00F4 AD77"
The key is imported.
gpg: reading options from '/home/amnesia/.gnupg/gpg.conf'
gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog
gpg: DBG: [not enabled in the source] start
gpg: DBG: chan_3 <- # Home: /home/amnesia/.gnupg
gpg: DBG: chan_3 <- # Config: /home/amnesia/.gnupg/dirmngr.conf
gpg: DBG: chan_3 <- OK Dirmngr 2.1.18 at your service
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_3
gpg: DBG: chan_3 <
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3
gpg: keyserver receive failed: Connection timed out
#7 Updated by fowlslegs over 2 years ago
gpg --keyserver hkp://pool.sks-keyservers.net --recv-key "2224 5C81 E3BA EB41 38B3 6061 310F 5612 00F4 AD77"
fails on Tails 3 beta 4 with error message
gpg:keyserver receive failed: No keyserver available.
So at least for me @redshiftzero's workaround does not seem to work. That said the default keyserver is described as an "experimental Tor OnionBalance hidden service is running as hkp://jirk5u4osbsr34t5.onion consisting of the servers marked with Tor support in the status list as backend," which IMO Tails should re-consider using by default precisely because of it's experimental nature and the fact it doesn't seem highly reliable.
As @intrigeri correctly points out and as discussed further in https://github.com/freedomofpress/securedrop/pull/1804, there is not much "trusting" of keyservers. Would it not be better to simply go back to using the HKPS SKS keyservers, which seem to have greater uptime/ reliability? I'll leave that question up to the Tails team, but if I were part of it I think I would be arguing yes. As much as I like to use/ support use of onion services, use for keyservers/ keyserver pools combined with OnionBalance does in fact seem too experimental for inclusion in the default Tails GPG configuration.
I still encounter the same hangs with the default configuration, even in Tails 3.9.1. This issue was rejected a year ago in favor of monitoring long term trends; would it be possible to get an update on what the automated test suite shows in terms of reliability of the default configuration? Apologies if this is already covered in another issue I missed in search.
- Status changed from Rejected to Confirmed
- Assignee set to emmapeel
- QA Check set to Info Needed
I still encounter the same hangs with the default configuration,
even in Tails 3.9.1.
This issue was rejected a year ago in favor of monitoring long term trends; would it be possible to get an update on what the automated test suite shows in terms of reliability of the default configuration?
Sadly, we're not going to get the data I expected this way: we don't use this keyserver in our test suite anymore since we started using Chutney (#12211).
So to monitor long term trends, we'll need to rely on feedback from our users, such as your report ⇒ dear emmapeel, how frequently do users report issues with fetching OpenPGP keys from keyservers?
Buster 10.1 will have gnupg2 2.2.12-1+deb10u1. This includes one change that's relevant here: "use keys.openpgp.org as the default keyserver". Note, however, that this change won't affect Tails as-is, because we configure our own keyserver (
git grep -F jirk5u4osbsr34t5.onion; and IIRC Torbirdy does the same for Enigmail); these settings can have been copied to persistent