Hi,

I figured out why one of those ansible lines works and the other doesn't if you're interested :)

On 10/07/17 22:58, tor wrote:

Actually, the directions on https://www.torproject.org/docs/debian.html.en work okay. I was trying to automate things with Ansible, but the format changed at some point, from something like:

apt_key: id=A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 url=http://keys.gnupg.net/pks/lookup?op=get&search=A3C4F0F979CAA22CDBA8F512E...

... by explicitly setting the URL to http:// it'll try and use port 80 rather than the default HKP port of 11371.

It's like doing `gpg --recv-key <id> --keyserver keys.gnupg.net:80`

to:

apt_key: id=A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 keyserver=keys.gnupg.net

The URL at /pks/lookup no longer exists, so I saw a 404. Using the newer format with just the hostname of the keyserver it works okay.

Regarding http://keys.gnupg.net I still don't know why there is a SSL mismatch in the browser, or why you can no longer access the web UI, but it's not as broken as it looked.

The problem is that the keyservers can do what they like on port 80 - to be included in the *default* pool they have to meet a set of criteria on the HKP port, 11371.

It's allowed, if totally confusing, for a keyserver to redirect port 80 traffic to an HTTPS domain with a mismatching cert. (Now I've realised mine does that I'm going to fix it: it should only try and redirect keyserver.paulfurley.com to HTTPS)

*Some* keyservers choose to behave "correctly" on port 80, and those keyservers end up in another pool called p80.pool.sks-keyservers.net.

keys.gnupg.net is an alias for pool.sks-keyservers.net, so the only guarantee for keys.gnupg.net is that you can use it over the default HKP port, e.g. `gpg --keyserver keys.gnupg.net ...`

Cheers, Paul