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

Fri Sep 11 18:34:38 CEST 2026

On 2026-09-11 11:24, Werner Koch wrote:
> On Thu, 10 Sep 2026 16:40, Torbjorn SVENSSON said:
> 
>> I'd love to do that, but every attempt that I've done to access
>> https://dev.gnupg.org/ has resulted in PR_CONNECT_RESET_ERROR.
> 
> Sorry for this.  Those ^%&%&% AI scrapers just drive us crazy and thus
> we still need to blacklist most of the net.  But they have not yet taken
> over mailing lists, thus please post bug reports here.
I don't know what format you want this in, so I'll just use plain text.

Bug report:

If the host running gpg has no route to the Internet and the DNS does not
resolve any public domains, gpg will fail to download the public key from a
keyserver, even if configured to go through a proxy server.

In https://lists.gnupg.org/pipermail/gnupg-devel/2026-September/036385.html,
I attached a small docker setup where this can be verified. In the demo,
there is no custom binary or anything alike. The input to the "run-test.sh"
script is a path to a git clone of the gpg source tree and the tree will
be copied into the container and built inside.
I also added a patch in that email that I'm using below.

If I run the demo on the 53ee642e2cc10b6a0bcb69c6d3f788deef2eac7a commit, with

debug ipc,network,dns
log-file /tmp/dirmngr.log

in $work/dirmngr.conf (as requested in
https://lists.gnupg.org/pipermail/gnupg-devel/2026-September/036386.html), I
get the following in the dirmngr.log file (I've taken the liberty to remove
the timestamp):

dirmngr[12] listening on socket '/tmp/tmp.lktzYbo0YT/S.dirmngr'
dirmngr[13.0] error loading certificate '/etc/ssl/certs/ca-certificates.crt': Certificate expired
dirmngr[13.0] error loading certificate '/etc/ssl/certs/ca-certificates.crt': Certificate expired
dirmngr[13.0] permanently loaded certificates: 129
dirmngr[13.0]     runtime cached certificates: 0
dirmngr[13.0]            trusted certificates: 129 (129,0,0,0)
dirmngr[13.0] failed to open cache dir file '/tmp/tmp.lktzYbo0YT/crls.d/DIR.txt': No such file or directory
dirmngr[13.0] creating directory '/tmp/tmp.lktzYbo0YT/crls.d'
dirmngr[13.0] new cache dir file '/tmp/tmp.lktzYbo0YT/crls.d/DIR.txt' created
dirmngr[13.6] handler for fd 6 started
dirmngr[13.6] DBG: chan_6 -> # Home: /tmp/tmp.lktzYbo0YT
dirmngr[13.6] DBG: chan_6 -> # Config: /tmp/tmp.lktzYbo0YT/dirmngr.conf
dirmngr[13.6] DBG: chan_6 -> OK Dirmngr 2.5.23-beta6 at your service, process 13
dirmngr[13.6] connection from process 1 (0:0)
dirmngr[13.6] DBG: chan_6 <- GETINFO version
dirmngr[13.6] DBG: chan_6 -> D 2.5.23-beta6
dirmngr[13.6] DBG: chan_6 -> OK
dirmngr[13.6] DBG: chan_6 <- OPTION http-proxy=http://172.28.0.2:3128
dirmngr[13.6] DBG: chan_6 -> OK
dirmngr[13.6] DBG: chan_6 <- KEYSERVER --clear hkps://keyserver.ubuntu.com
dirmngr[13.6] DBG: chan_6 -> OK
dirmngr[13.6] DBG: chan_6 <- KS_GET -- 0x1493269DE61F124AA69A316E3ADF34EBDBB200A4
dirmngr[13.6] DBG: dns: libdns initialized
dirmngr[13.6] DBG: dns: getsrv(_pgpkey-https._tcp.keyserver.ubuntu.com): Server indicated a failure
dirmngr[13.6] command 'KS_GET' failed: Server indicated a failure <Unspecified source>
dirmngr[13.6] DBG: chan_6 -> ERR 219 Server indicated a failure <Unspecified source>
dirmngr[13.6] DBG: chan_6 <- BYE
dirmngr[13.6] DBG: chan_6 -> OK closing connection
dirmngr[13.6] handler for fd 6 terminated

With my patched applied on top, I instead get this:

dirmngr[12] listening on socket '/tmp/tmp.1u46BWZXep/S.dirmngr'
dirmngr[13.0] error loading certificate '/etc/ssl/certs/ca-certificates.crt': Certificate expired
dirmngr[13.0] error loading certificate '/etc/ssl/certs/ca-certificates.crt': Certificate expired
dirmngr[13.0] permanently loaded certificates: 129
dirmngr[13.0]     runtime cached certificates: 0
dirmngr[13.0]            trusted certificates: 129 (129,0,0,0)
dirmngr[13.0] failed to open cache dir file '/tmp/tmp.1u46BWZXep/crls.d/DIR.txt': No such file or directory
dirmngr[13.0] creating directory '/tmp/tmp.1u46BWZXep/crls.d'
dirmngr[13.0] new cache dir file '/tmp/tmp.1u46BWZXep/crls.d/DIR.txt' created
dirmngr[13.6] handler for fd 6 started
dirmngr[13.6] DBG: chan_6 -> # Home: /tmp/tmp.1u46BWZXep
dirmngr[13.6] DBG: chan_6 -> # Config: /tmp/tmp.1u46BWZXep/dirmngr.conf
dirmngr[13.6] DBG: chan_6 -> OK Dirmngr 2.5.23-beta6 at your service, process 13
dirmngr[13.6] connection from process 1 (0:0)
dirmngr[13.6] DBG: chan_6 <- GETINFO version
dirmngr[13.6] DBG: chan_6 -> D 2.5.23-beta6
dirmngr[13.6] DBG: chan_6 -> OK
dirmngr[13.6] DBG: chan_6 <- OPTION http-proxy=http://172.28.0.2:3128
dirmngr[13.6] DBG: chan_6 -> OK
dirmngr[13.6] DBG: chan_6 <- KEYSERVER --clear hkps://keyserver.ubuntu.com
dirmngr[13.6] DBG: chan_6 -> OK
dirmngr[13.6] DBG: chan_6 <- KS_GET -- 0x1493269DE61F124AA69A316E3ADF34EBDBB200A4
dirmngr[13.6] DBG: dns: libdns initialized
dirmngr[13.6] DBG: dns: resolve_dns_name(keyserver.ubuntu.com): Server indicated a failure
dirmngr[13.6] resolving 'keyserver.ubuntu.com' failed: Server indicated a failure
dirmngr[13.6] number of system provided CAs: 131
dirmngr[13.6] DBG: Using TLS library: GNUTLS 3.8.12
dirmngr[13.6] DBG: http.c:connect_server: trying name='172.28.0.2' port=3128
dirmngr[13.6] DBG: dns: resolve_dns_name(172.28.0.2): Success
dirmngr[13.6] DBG: http.c:2893:socket_new: object 0x000075ca0435dcb0 for fd 7 created
dirmngr[13.6] DBG: http.c:proxy:request:
dirmngr[13.6] DBG: >> CONNECT keyserver.ubuntu.com:443 HTTP/1.1\r\n
dirmngr[13.6] DBG: >> Host: keyserver.ubuntu.com:443\r\n
dirmngr[13.6] DBG: >> Connection: keep-alive\r\n
dirmngr[13.6] DBG: http.c:request-header:start_data:
dirmngr[13.6] DBG: network read: 39/8192
dirmngr[13.6] DBG: http.c:response:
dirmngr[13.6] DBG: >> HTTP/1.1 200 Connection established\r\n
dirmngr[13.6] http.c:RESP: ''
dirmngr[13.6] DBG: http.c:request:
dirmngr[13.6] DBG: >> GET /pks/lookup?op=get&options=mr&search=0x1493269DE61F124AA69A316E3ADF34EBDBB200A4 HTTP/1.0\r\n
dirmngr[13.6] DBG: >> Host: keyserver.ubuntu.com\r\n
dirmngr[13.6] DBG: http.c:request-header:start_data:
dirmngr[13.6] DBG: http.c:response:
dirmngr[13.6] DBG: >> HTTP/1.1 200 OK\r\n
dirmngr[13.6] http.c:RESP: 'Date: Fri, 11 Sep 2026 15:53:49 GMT'
dirmngr[13.6] http.c:RESP: 'Server: Hockeypuck/2.2'
dirmngr[13.6] http.c:RESP: 'Access-Control-Allow-Origin: *'
dirmngr[13.6] http.c:RESP: 'Content-Type: application/pgp-keys'
dirmngr[13.6] http.c:RESP: 'Content-Length: 948'
dirmngr[13.6] http.c:RESP: 'Connection: close'
dirmngr[13.6] http.c:RESP: ''
dirmngr[13.6] DBG: chan_6 -> S SOURCE https://keyserver.ubuntu.com:443
dirmngr[13.6] DBG: (948 bytes sent via D lines not shown)
dirmngr[13.6] DBG: chan_6 -> OK
dirmngr[13.6] DBG: chan_6 <- BYE
dirmngr[13.6] DBG: chan_6 -> OK closing connection
dirmngr[13.6] handler for fd 6 terminated

The command that was executed:

gpg \
     --homedir "$work" \
     --batch \
     --keyserver hkps://keyserver.ubuntu.com \
     --keyserver-options "http-proxy=$http_proxy" \
     --recv-keys 1493269DE61F124AA69A316E3ADF34EBDBB200A4

Where "$work" is a temporary directory and "http_proxy" is the proxy
server to connect to.
In a real world scenario, the proxy server will likely also have
authentication, but I skipped that in the demo to make it easier to follow.

Obviously, they keyserver can be any URL and also the key to fetch.
Above are just two examples.

I've verified that issue exists in 2.4.5, 2.5.22 and on the master branch
(53ee642e2cc10b6a0bcb69c6d3f788deef2eac7a).

--

Hope this covers all areas. If there is something that I'm missing, please
don't hesitate to request more details.

Kind regards,
Torbjörn