Project

General

Profile

Feature #16575

Use a more reliable OpenPGP key server by default

Added by sajolida about 1 year ago. Updated about 1 year ago.

Status:
Duplicate
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
03/19/2019
Due date:
% Done:

0%

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

Description

I've had reliability problems when doing OpenPGP operations in Tails for months (years?). The output of the gpg is pretty unhelpful and, if I understood correctly, the issue is unreliable key servers. For example:

amnesia@amnesia:~$ gpg --recv-keys 0x2BD5824B7F9470E6
gpg: keyserver receive failed: No keyserver available

For some time, I've used keys.riseup.net whenever I experience a failed OpenPGP operation and it also always solves it. For example, after the previous error:

amnesia@amnesia:~$ gpg --keyserver keys.riseup.net --recv-keys 0x2BD5824B7F9470E6
gpg: key 0x2BD5824B7F9470E6: 167 signatures not checked due to missing keys
gpg: key 0x2BD5824B7F9470E6: "Thomas Voegtlin (https://electrum.org) <thomasv@electrum.org>" 2 new user IDs
gpg: key 0x2BD5824B7F9470E6: "Thomas Voegtlin (https://electrum.org) <thomasv@electrum.org>" 173 new signatures
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   1  signed:  46  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1  valid:  46  signed: 116  trust: 46-, 0q, 0n, 0m, 0f, 0u
gpg: next trustdb check due at 2019-03-19
gpg: Total number processed: 1
gpg:           new user IDs: 2
gpg:         new signatures: 173

Why don't we configure keys.riseup.net as the default OpenPGP key server in Tails since it proved to be much more reliable than the current state of things?


Related issues

Related to Tails - Bug #17090: Use keys.openpgp.org as the default key server Duplicate
Duplicates Tails - Bug #12689: gpg --recv-key often hangs due to unreliable keyserver Resolved 06/13/2017

History

#1 Updated by intrigeri about 1 year ago

I've had reliability problems when doing OpenPGP operations in Tails for months (years?). The output of the gpg is pretty unhelpful and, if I understood correctly, the issue is unreliable key servers.

Right. I think we've always had such problems but it got much worse since we switched to the onion service (in 3.0 IIRC).

My own workaround is: systemctl --user restart dirmngr.service (no sudo!).

For some time, I've used keys.riseup.net whenever I experience a failed OpenPGP operation and it also always solves it.

FTR, it seems that keys.riseup.net is the same as zimmermann.mayfirst.org, which is in various pools. It's actually one of the 6 servers currently in the onion service pool. Except keys.riseup.net has no valid TLS certificate; you're using it in cleartext anyway.

Why don't we configure keys.riseup.net as the default OpenPGP key server in Tails since it proved to be much more reliable than the current state of things?

We've switched to this onion service (3c68e5ff4cc0dd38dad2e69e4627f03292d834e1) because when using the HKPS pool (hkps://hkps.pool.sks-keyservers.net), which is backed with DNS load balancing, dirmngr will get both IPv4 and IPv6 addresses when resolving the hostname, due to the way its use-tor option works. If it gets an IPv6 address, given we haven't configured Tor to do IPv6 and we by and large we block IPv6, then fetching a key will fail.

So in our current config, keys.riseup.net works reliably for you only because there's no AAAA DNS record for it. As soon as Riseup adds one, this workaround will become unreliable. That doesn't feel like a good bet to me.

We could certainly revert back to the HKPS pool or use https://zimmermann.mayfirst.org/ (which has a AAAA record). To make this work reliably, we'll need to enable IPv6 in our torrc, then mangle the firewall and possibly the test suite accordingly. It might be a matter of a 2-4 hours, it might be much harder. Hard to tell without trying :)

Either way, if we don't do anything else:

  • For GnuPG on the command line, it'll only affect brand new persistent configurations and non-persistent ones.
  • There's a good chance Enigmail keeps using the onion service (we patched it upstream to make it do that, to fix #11948). Changing this needs extra work.

In passing, using an onion service has another advantage in theory: it gives end-to-end encryption and authentication of the server in Seahorse, which doesn't support hkps://.

I hope I've satisfied your curiosity :)

Now, well, I'm not sure any of this is worth the effort. In any case, I'm going to merge this with #12689.

#2 Updated by intrigeri about 1 year ago

  • Duplicates Bug #12689: gpg --recv-key often hangs due to unreliable keyserver added

#3 Updated by intrigeri about 1 year ago

  • Status changed from New to Duplicate

#4 Updated by sajolida 6 months ago

  • Related to Bug #17090: Use keys.openpgp.org as the default key server added

Also available in: Atom PDF