2.0.20 breaks DNS SRV hkp keyserver access via web proxy server

[David Shaw]

On Jun 13, 2013, at 3:18 AM, John Marshall <john.marshall at riverwillow.com.au> wrote:

> On Thu, 13 Jun 2013, 00:13 -0400, David Shaw wrote:
> 
>> I'm not convinced that it makes sense for a client to resolve the SRV, and then pass the resulting hostname to a proxy.  For example, leaving aside SRV, the client does not try and resolve an A record or chase a CNAME, but rather passes the requested resource to the proxy and the proxy does the work translating that to a DNS name, looking up that name, making the connection, etc.  Indeed, the client may not even be able to resolve external DNS at all.
> 
> I think you're right.  Here am I complaining about 2.0.20 breaking that
> functionality and it should never have been there in the first place.
> So why is the gnupg client doing DNS work for hkp(s) in the presence of
> a configured HTTP proxy server?

Bug.  It shouldn't be.

> Couldn't this work (gnupg doing SRV selection) with a SOCKS5 proxy?  I
> can't find SOCKS in the man page or in the source code.  Are there any
> plans for gnupg to support keyserver connection via a SOCKS5 proxy?

As you discovered, SOCKS5 does work - we get this for free because libcurl supports it.  There is a gotcha with all this proxy stuff, however.  If you're going over something like TOR, you are effectively "leaking" what queries you are doing because GPG will do the keyserver SRV request through the local DNS before sending the actual keyserver query through TOR.

I wonder if the healthiest thing to do here is to just flip SRV to off if any proxy is provided.  If the user chooses to turn it back on again, that's up to them, but it should default to off.

Comments from people using TOR would be welcome!

David