[PATCH GnuPG] dirmngr: Fix HKP keyserver access via HTTP proxy

[Steffen Nurpmeso]

Torbjorn SVENSSON via Gnupg-devel wrote in
 <e38f2e05-980f-402a-8347-07cd55bd7cce at foss.st.com>:
 |On 2026-10-08 19:39, Andrew Gallagher wrote:
 |> On 08/10/2026 16:11, Torbjorn SVENSSON wrote:
 |>> I understand that some proxy solutions might allow DNS lookup, but \
 |>> the scenario that I have does not.
 |> 
 |> Got it, thanks. Would it not be better then to have a separate option \
 |> for this, rather than modifying the behaviour of all proxied clients \
 |> whether they need it or not?. We could add heavy caveats to the document\
 |> ation of this new option ("beware that SRV and round-robin will not \
 |> work") so that the change in behaviour does not take anyone by surprise.
 |
 |Sure, that could be done, but how would a user understand the difference \
 |between a proxy with local DNS lookup and a proxy that does the DNS \
 |lookup for the client?
 |Also, not sure why round-robin would not work with a proxy server in \
 |the middle. The proxy server will still look up, at least, the A/AAAA \
 |record in order to know where to connect. What other type of round-robin \
 |are you talking about?
 |If it's the explicit SRV record, then I suppose that will not be quivere\
 |d...
 |
 |Since there were no response from this list, I managed to avoid the \
 |urgency with this workaround:
 |https://github.com/SonarSource/sonarqube-scan-action/commit/6abe0a79df7d\
 |9decfbdd73f06e1a7cac404a8562#diff-c8da56253811b1775e3a73059d9b3caedb3c38\
 |5029c8639c083b823dd0b47d8dR258
 |It's not pretty, but it avoids the failure in our CI at least.
 |
 |Note, the current version of gpg is still not working in our dev. enviro\
 |nment since those computers have the same restriction, i.e., they only \
 |have access to the internet via a proxy server. So even with the workaro\
 |und for our CI, the pain is still real from this bug.
 |
 |So, going back to your question; What would the option be named and \
 |how would a user be able to understand the difference?

As far as i know, and Werner Koch said something so, gnupg does
support wrapping via TOR.  Now TOR is practically nothing but
SOCKS5 aka RFC 1928, even restricted so, with as far as i know
(from a file i downloaded on 2017-05-26) only mostly one
extension, and that is:

  2. Name lookup

  As an extension to SOCKS4A and SOCKS5, Tor implements a new command value,
  "RESOLVE" [F0].  When Tor receives a "RESOLVE" SOCKS command, it initiates
  a remote lookup of the hostname provided as the target address in the SOCKS
  request.  The reply is either an error (if the address couldn't be
  resolved) or a success response.  In the case of success, the address is
  stored in the portion of the SOCKS response reserved for remote IP address.

  (We support RESOLVE in SOCKS4 too, even though it is unnecessary.)

  For SOCKS5 only, we support reverse resolution with a new command value,
  "RESOLVE_PTR" [F1]. In response to a "RESOLVE_PTR" SOCKS5 command with
  an IPv4 address as its target, Tor attempts to find the canonical
  hostname for that IPv4 record, and returns it in the "server bound
  address" portion of the reply.
  (This command was not supported before Tor 0.1.2.2-alpha.)

I would think this is pretty easy to do, at least a normal SOCKS5
client can be done in less than 100 lines (you can have code from
my MUA, or look at the lynx browser, which has similar).
(I was then grep(1)ping gnupg code, and it seems they use that
resolve extension.)

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)