Page MenuHome GnuPG

Keyserver access via http-proxy isn't attempted when using standard-resolver
Open, HighPublic

Description

When fetching keys for Gentoo signature verification, we're using the following configuration options for maximum compatibility with different system configurations:

honor-http-proxy
# this one added recently
standard-resolver

After adding standard-resolver (which fixed problems for a few users), we've gotten a report that it breaks fetching keys from our keyserver through HTTP proxy. FWIU the user's system can't access keys.gentoo.org directly and needs to go through their local proxy.

Apparently without standard-resolver, the following happens:

  1. single SRV lookup for _pgpkey-https._tcp.keys.gentoo.org
  2. single A lookup for keys.gentoo.org
  3. several CONNECT keys.gentoo.org:443 (permitted by proxy)

While with standard-resolver, it loops on retrying the SRV lookup and never gets past it.

Original bug report: https://bugs.gentoo.org/906875

I've been able to reproduce myself using the following procedure, though i'm not 100% sure that it triggers the same code path:

  1. Start a working proxy (e.g. I've started tinyproxy -d after installing, no config needed).
  2. Create a container (I've used systemd-nspawn but I think chroot will work too).
  3. "Block" the keyserver via /etc/hosts: 192.168.100.100 keys.gentoo.org (this is an unused address here).
  4. Create a dirmngr.conf with standard-resolver and http-proxy http://127.0.0.1:8888.
  5. Attempt gpg --keyserver hkps://keys.gentoo.org --recv-keys 3408B1B906EB579B41D9CB0CDF84256885283521

The log (with debug-all, debug-level guru:

2023-05-22 07:05:36 dirmngr[111889] listening on socket '/tmp/test1/S.dirmngr'
2023-05-22 07:05:36 dirmngr[111890.0] error loading certificate '/etc/ssl/certs/ca-certificates.crt': Certificate expired
2023-05-22 07:05:36 dirmngr[111890.0] error loading certificate '/etc/ssl/certs/ca-certificates.crt': Certificate expired
2023-05-22 07:05:36 dirmngr[111890.0] permanently loaded certificates: 140
2023-05-22 07:05:36 dirmngr[111890.0]     runtime cached certificates: 0
2023-05-22 07:05:36 dirmngr[111890.0]            trusted certificates: 140 (140,0,0,0)
2023-05-22 07:05:36 dirmngr[111890.6] handler for fd 6 started
2023-05-22 07:05:36 dirmngr[111890.6] DBG: chan_6 -> # Home: /tmp/test1
2023-05-22 07:05:36 dirmngr[111890.6] DBG: chan_6 -> # Config: /tmp/test1/dirmngr.conf
2023-05-22 07:05:36 dirmngr[111890.6] DBG: chan_6 -> OK Dirmngr 2.4.0 at your service
2023-05-22 07:05:36 dirmngr[111890.6] connection from process 111888 (0:0)
2023-05-22 07:05:36 dirmngr[111890.6] DBG: chan_6 <- GETINFO version
2023-05-22 07:05:36 dirmngr[111890.6] DBG: chan_6 -> D 2.4.0
2023-05-22 07:05:36 dirmngr[111890.6] DBG: chan_6 -> OK
2023-05-22 07:05:36 dirmngr[111890.6] DBG: chan_6 <- KEYSERVER --clear hkps://keys.gentoo.org
2023-05-22 07:05:36 dirmngr[111890.6] DBG: chan_6 -> OK
2023-05-22 07:05:36 dirmngr[111890.6] DBG: chan_6 <- KS_GET -- 0x3408B1B906EB579B41D9CB0CDF84256885283521
2023-05-22 07:05:36 dirmngr[111890.6] DBG: dns: getsrv(_pgpkey-https._tcp.keys.gentoo.org): General error
2023-05-22 07:05:36 dirmngr[111890.6] command 'KS_GET' failed: General error
2023-05-22 07:05:36 dirmngr[111890.6] DBG: chan_6 -> ERR 167772161 General error <Dirmngr>
2023-05-22 07:05:36 dirmngr[111890.6] DBG: chan_6 <- BYE
2023-05-22 07:05:36 dirmngr[111890.6] DBG: chan_6 -> OK closing connection
2023-05-22 07:05:36 dirmngr[111890.6] handler for fd 6 terminated

For comparison, without standard-resolver, it resolves the address successfully, then connects via HTTPS proxy:

2023-05-22 07:06:49 dirmngr[111914] listening on socket '/tmp/test1/S.dirmngr'
2023-05-22 07:06:49 dirmngr[111915.0] error loading certificate '/etc/ssl/certs/ca-certificates.crt': Certificate expired
2023-05-22 07:06:49 dirmngr[111915.0] error loading certificate '/etc/ssl/certs/ca-certificates.crt': Certificate expired
2023-05-22 07:06:49 dirmngr[111915.0] permanently loaded certificates: 140
2023-05-22 07:06:49 dirmngr[111915.0]     runtime cached certificates: 0
2023-05-22 07:06:49 dirmngr[111915.0]            trusted certificates: 140 (140,0,0,0)
2023-05-22 07:06:49 dirmngr[111915.6] handler for fd 6 started
2023-05-22 07:06:49 dirmngr[111915.6] DBG: chan_6 -> # Home: /tmp/test1
2023-05-22 07:06:49 dirmngr[111915.6] DBG: chan_6 -> # Config: /tmp/test1/dirmngr.conf
2023-05-22 07:06:49 dirmngr[111915.6] DBG: chan_6 -> OK Dirmngr 2.4.0 at your service
2023-05-22 07:06:49 dirmngr[111915.6] connection from process 111913 (0:0)
2023-05-22 07:06:49 dirmngr[111915.6] DBG: chan_6 <- GETINFO version
2023-05-22 07:06:49 dirmngr[111915.6] DBG: chan_6 -> D 2.4.0
2023-05-22 07:06:49 dirmngr[111915.6] DBG: chan_6 -> OK
2023-05-22 07:06:49 dirmngr[111915.6] DBG: chan_6 <- KEYSERVER --clear hkps://keys.gentoo.org
2023-05-22 07:06:49 dirmngr[111915.6] DBG: chan_6 -> OK
2023-05-22 07:06:49 dirmngr[111915.6] DBG: chan_6 <- KS_GET -- 0x3408B1B906EB579B41D9CB0CDF84256885283521
2023-05-22 07:06:49 dirmngr[111915.6] DBG: dns: libdns initialized
2023-05-22 07:06:49 dirmngr[111915.6] DBG: dns: getsrv(_pgpkey-https._tcp.keys.gentoo.org) -> 0 records
2023-05-22 07:06:50 dirmngr[111915.6] DBG: dns: resolve_dns_name(keys.gentoo.org): Success
2023-05-22 07:06:50 dirmngr[111915.6] resolve_dns_addr for 'keys.gentoo.org': 'keys.gentoo.org' [already known]
2023-05-22 07:06:50 dirmngr[111915.6] resolve_dns_addr for 'keys.gentoo.org': 'keys.gentoo.org' [already known]
2023-05-22 07:06:50 dirmngr[111915.6] number of system provided CAs: 142
2023-05-22 07:06:50 dirmngr[111915.6] DBG: Using TLS library: GNUTLS 3.8.0
2023-05-22 07:06:50 dirmngr[111915.6] DBG: http.c:connect_server: trying name='127.0.0.1' port=8888
2023-05-22 07:06:50 dirmngr[111915.6] DBG: dns: resolve_dns_name(127.0.0.1): Success
2023-05-22 07:06:50 dirmngr[111915.6] DBG: http.c:1951:socket_new: object 0x00007f5eec318840 for fd 7 created
2023-05-22 07:06:50 dirmngr[111915.6] DBG: http.c:request:
2023-05-22 07:06:50 dirmngr[111915.6] DBG: >> CONNECT keys.gentoo.org:443 HTTP/1.0\r\n
2023-05-22 07:06:50 dirmngr[111915.6] DBG: >> Host: keys.gentoo.org:443\r\n
2023-05-22 07:06:50 dirmngr[111915.6] DBG: http.c:request-header:
2023-05-22 07:06:50 dirmngr[111915.6] DBG: >> \r\n
2023-05-22 07:06:50 dirmngr[111915.6] DBG: http.c:response:
2023-05-22 07:06:50 dirmngr[111915.6] DBG: >> HTTP/1.0 200 Connection established\r\n
2023-05-22 07:06:50 dirmngr[111915.6] http.c:RESP: 'Proxy-agent: tinyproxy/1.11.1'
2023-05-22 07:06:50 dirmngr[111915.6] http.c:RESP: ''
2023-05-22 07:06:50 dirmngr[111915.6] DBG: http.c:request:
2023-05-22 07:06:50 dirmngr[111915.6] DBG: >> GET /pks/lookup?op=get&options=mr&search=0x3408B1B906EB579B41D9CB0CDF84256885283521 HTTP/1.0\r\n
2023-05-22 07:06:50 dirmngr[111915.6] DBG: >> Host: keys.gentoo.org\r\n
2023-05-22 07:06:50 dirmngr[111915.6] DBG: http.c:request-header:
2023-05-22 07:06:50 dirmngr[111915.6] DBG: >> \r\n
2023-05-22 07:06:50 dirmngr[111915.6] DBG: http.c:response:
2023-05-22 07:06:50 dirmngr[111915.6] DBG: >> HTTP/1.1 200 OK\r\n
2023-05-22 07:06:50 dirmngr[111915.6] http.c:RESP: 'Server: nginx'
2023-05-22 07:06:50 dirmngr[111915.6] http.c:RESP: 'Date: Mon, 22 May 2023 05:06:50 GMT'
2023-05-22 07:06:50 dirmngr[111915.6] http.c:RESP: 'Content-Type: application/pgp-keys; charset=UTF-8'
2023-05-22 07:06:50 dirmngr[111915.6] http.c:RESP: 'Content-Length: 112841'
2023-05-22 07:06:50 dirmngr[111915.6] http.c:RESP: 'Connection: close'
2023-05-22 07:06:50 dirmngr[111915.6] http.c:RESP: 'Cache-Control: no-cache'
2023-05-22 07:06:50 dirmngr[111915.6] http.c:RESP: 'Pragma: no-cache'
2023-05-22 07:06:50 dirmngr[111915.6] http.c:RESP: 'Expires: 0'
2023-05-22 07:06:50 dirmngr[111915.6] http.c:RESP: 'X-HKP-Results-Count: 1'
2023-05-22 07:06:50 dirmngr[111915.6] http.c:RESP: 'Content-disposition: attachment; filename=gpgkey.asc'
2023-05-22 07:06:50 dirmngr[111915.6] http.c:RESP: 'Access-Control-Allow-Origin: *'
2023-05-22 07:06:50 dirmngr[111915.6] http.c:RESP: 'X-Frame-Options: DENY'
2023-05-22 07:06:50 dirmngr[111915.6] http.c:RESP: ''
2023-05-22 07:06:50 dirmngr[111915.6] DBG: chan_6 -> S SOURCE https://keys.gentoo.org:443
2023-05-22 07:06:50 dirmngr[111915.6] DBG: (112841 bytes sent via D lines not shown)
2023-05-22 07:06:50 dirmngr[111915.6] DBG: chan_6 -> OK
2023-05-22 07:06:50 dirmngr[111915.6] DBG: chan_6 <- BYE
2023-05-22 07:06:50 dirmngr[111915.6] DBG: chan_6 -> OK closing connection
2023-05-22 07:06:50 dirmngr[111915.6] handler for fd 6 terminated

Details

Version
2.4.0

Event Timeline

Ok, it seems that my reproducer isn't correct after all. The user just confirmed that the SRV lookup succeeds on their system, so it seems GPG hits some loop repeating that for no apparent reason.

werner added a subscriber: werner.

Seems it gets a record but is not able to parse it (gnupg/dirmngr/dns-stuff.c:getsrv-standard) in your setup. Not sure why it loops - need to debug it.

For the record, we've removed the SRV record for keys.gentoo.org for now, to work around the problem. Without the SRV record, everything works as expected.

@werner, please let me know if you need us to reinstate it for you to be able to debug it.

werner triaged this task as High priority.