Project

General

Profile

Bug #12689

gpg --recv-key often hangs due to unreliable keyserver

Added by dachary over 2 years ago. Updated 17 days ago.

Status:
Confirmed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
06/13/2017
Due date:
% Done:

0%

Feature Branch:
Type of work:
Research
Blueprint:
Starter:
Affected tool:

Description

description

    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
    use-tor
    keyserver hkp://jirk5u4osbsr34t5.onion
  • gpg --debug-all --recv-key "2224 5C81 E3BA EB41 38B3 6061 310F 5612 00F4 AD77"

Expected Behavior

The key is imported.

Actual Behavior


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 > GETINFO version
gpg: DBG: chan_3 <
D 2.1.18
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 > KS_GET - 0x22245C81E3BAEB4138B36061310F561200F4AD77
gpg: keyserver receive failed: Connection timed out

Related issues

Duplicated by Tails - Feature #16575: Use a more reliable OpenPGP key server by default Duplicate 03/19/2019
Blocks Tails - Bug #14770: "Fetching OpenPGP keys" scenarios are fragile: communication failure with keyserver In Progress 10/04/2017
Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed

History

#1 Updated by redshiftzero over 2 years ago

I also see this behavior, it looks like the issue is with the hkp server jirk5u4osbsr34t5.onion, e.g.:

gpg --keyserver hkp://pool.sks-keyservers.net --recv-key "2224 5C81 E3BA EB41 38B3 6061 310F 5612 00F4 AD77"

works.

#2 Updated by goupille over 2 years ago

  • Assignee set to goupille
  • Type of work changed from Debian to Research

I couldn't reproduce this issue with tails 3.0, could you try yourself ?

#3 Updated by dachary over 2 years ago

Today it works for me as well. I guess the server was down for a day or so ?

#4 Updated by intrigeri over 2 years ago

  • Status changed from New to Rejected
  • Assignee deleted (goupille)

Our automated test suite also has identified some on & off issues with that keyserver pool. We can keep track of this problem this way, and if it comes back more often we should come back here.

#5 Updated by dachary over 2 years ago

Is there a workaround for when the default server is down ? I suppose it is included by default because it is trusted. Are there other trusted key servers to be used when this one is not available ?

#6 Updated by intrigeri over 2 years ago

https://sks-keyservers.net/overview-of-pools.php

(But no, there's not really any "trusting" involved.)

#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.

#8 Updated by eloquence 11 months ago

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.

#9 Updated by intrigeri 10 months ago

  • Related to Bug #14770: "Fetching OpenPGP keys" scenarios are fragile: communication failure with keyserver added

#10 Updated by intrigeri 10 months ago

  • Related to deleted (Bug #14770: "Fetching OpenPGP keys" scenarios are fragile: communication failure with keyserver)

#11 Updated by intrigeri 10 months ago

  • 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?

#12 Updated by intrigeri 6 months ago

  • Assignee deleted (emmapeel)
  • QA Check deleted (Info Needed)

As a user of this keyserver myself, I confirm it's not up and working all the time.

#13 Updated by intrigeri 6 months ago

  • Duplicated by Feature #16575: Use a more reliable OpenPGP key server by default added

#14 Updated by intrigeri 6 months ago

#16575 has more info and ideas.

#15 Updated by intrigeri 6 months ago

The "keyserver network dying" thread on the monkeysphere mailing list (started on 2019-04-02) suggests that not only the Onion keyservers pool has problems these days.

#16 Updated by intrigeri 19 days ago

  • Subject changed from gpg --recv-key hangs to gpg --recv-key often hangs due to unreliable keyserver

This is one of the main cause of test suite failures these days (#14770).

#17 Updated by intrigeri 19 days ago

  • Blocks Bug #14770: "Fetching OpenPGP keys" scenarios are fragile: communication failure with keyserver added

#18 Updated by intrigeri 19 days ago

#19 Updated by intrigeri 17 days ago

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 ~/.gnupg/dirmngr.conf.

Also available in: Atom PDF