Tails

#2 Updated by intrigeri 2015-05-05 18:51:22

> As is clear in the comments of Bug #9095 our current key server (well, pool), hkps.pool.sks-keyservers.net, is not very reliable.

AFAIK it’s the only pool with hkps:// enabled. Replacing it with one single server may not be much more reliable (well, it may have less temporary errors, but it also will have longer continuous downtimes, I guess). How about getting in touch with that pool’s maintainers to check if they can make it more reliable, e.g. by actively detecting faulty servers and removing them from the pool? I believe that dkg (who reads tails-dev@) is kinda involved in that pool, so perhaps we should start with asking him :)

#3 Updated by anonym 2015-06-11 15:31:49

intrigeri wrote:
> I believe that dkg (who reads tails-dev@) is kinda involved in that pool, so perhaps we should start with asking him :)

Sent an email.

#4 Updated by dkg 2015-06-11 17:41:12

The person to talk to about the pool in more detail is Kristian Fiskerstrand (OpenPGP key 0x94CBAFDD30345109561835AA0B7F8B60E3EDFAE3, usually K_F on irc.oftc.net).

You may be having (at least) three different and distinct problems:

0. In some versions of seahorse, seahorse itself tries to speak HKPS directly, rather than relying on GnuPG to do the connection. I don’t know how robust Seahorse’s HTTPS code is.
1. some of the keyservers in the pool may be “down” to tor exit nodes but not down to the scripts that keep the DNS round-robin pool healthy.
2. the decisions about which member of the pool to select (by whatever backend: seahorse or gnupg) may not be keeping track of the number of different members of the pool and whether they’re currently reachable. In 2.1.x, all keyserver access is delegated to `dirmngr`, which is a long-running daemon that keeps track of known host availability (by name+IP address) and directs traffic to available hosts.

#5 Updated by dkg 2015-06-11 17:43:58

As one of the debian gnupg maintainers, i can verify that i don’t think tails is ready to switch to gnupg 2.1.x (and therefore to dirmngr) right now — but longer-term, i think that is the correct path. I don’t this isn’t particularly helpful for the short-term decision-making, though.

#6 Updated by dkg 2015-06-11 18:11:56

one last note: the pools are maintained in an automated way already with active queries and DNS records pruned regularly.

It’s possible that the tails tests are somehow more in-depth than the pools.sks-keyservers.net tests are, though, so maybe there’s something that tails folks are catching but the pools tests are not?

#9 Updated by anonym 2015-09-14 07:09:56

Given my test in Feature #9530, I guess the real issues are Tor-related. I guess we should just skip this, and document that users must retry upon failure (which we already do in our automated tests).