Tails

#1 Updated by intrigeri 2019-03-23 19:05:26

> 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 (commit: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 Bug #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 Bug #12689.