Odd behavior for HTTP(S) scheme in --keyserver config
Open, LowPublic

Description

gpg --keyserver https://keys.openpgp.org/ --recv-keys D4AB192964F76A7F8F8A9B357BD18320DEADFA11
2019-07-10 16:41:57 dirmngr[30976.6] DBG: chan_6 -> OK Dirmngr 2.2.16 at your service
2019-07-10 16:41:57 dirmngr[30976.6] connection from process 31081 (1000:1000)
2019-07-10 16:41:57 dirmngr[30976.6] DBG: chan_6 <- GETINFO version
2019-07-10 16:41:57 dirmngr[30976.6] DBG: chan_6 -> D 2.2.16
2019-07-10 16:41:57 dirmngr[30976.6] DBG: chan_6 -> OK
2019-07-10 16:41:57 dirmngr[30976.6] DBG: chan_6 <- KEYSERVER --clear https://keys.openpgp.org/
2019-07-10 16:41:57 dirmngr[30976.6] DBG: chan_6 -> OK
2019-07-10 16:41:57 dirmngr[30976.6] DBG: chan_6 <- KS_GET -- 0xD4AB192964F76A7F8F8A9B357BD18320DEADFA11
2019-07-10 16:41:58 dirmngr[30976.6] DBG: http.c:request:
2019-07-10 16:41:58 dirmngr[30976.6] DBG: >> GET / HTTP/1.0\r\n
2019-07-10 16:41:58 dirmngr[30976.6] DBG: >> Host: keys.openpgp.org\r\n
2019-07-10 16:41:58 dirmngr[30976.6] DBG: http.c:request-header:
2019-07-10 16:41:58 dirmngr[30976.6] DBG: >> \r\n
2019-07-10 16:41:58 dirmngr[30976.6] DBG: chan_6 -> S PROGRESS tick ? 0 0
2019-07-10 16:41:58 dirmngr[30976.6] DBG: http.c:response:
2019-07-10 16:41:58 dirmngr[30976.6] DBG: >> HTTP/1.1 200 OK\r\n
2019-07-10 16:41:58 dirmngr[30976.6] http.c:RESP: 'Server: nginx/1.14.2'
2019-07-10 16:41:58 dirmngr[30976.6] http.c:RESP: 'Date: Wed, 10 Jul 2019 14:41:58 GMT'
2019-07-10 16:41:58 dirmngr[30976.6] http.c:RESP: 'Content-Type: text/html; charset=utf-8'
2019-07-10 16:41:58 dirmngr[30976.6] http.c:RESP: 'Content-Length: 1624'
2019-07-10 16:41:58 dirmngr[30976.6] http.c:RESP: 'Connection: close'
2019-07-10 16:41:58 dirmngr[30976.6] http.c:RESP: 'Vary: Accept-Encoding'
2019-07-10 16:41:58 dirmngr[30976.6] http.c:RESP: 'X-Frame-Options: SAMEORIGIN'
2019-07-10 16:41:58 dirmngr[30976.6] http.c:RESP: 'X-XSS-Protection: 1; mode=block'
2019-07-10 16:41:58 dirmngr[30976.6] http.c:RESP: 'X-Content-Type-Options: nosniff'
2019-07-10 16:41:58 dirmngr[30976.6] http.c:RESP: 'Referrer-Policy: no-referrer-when-downgrade'
2019-07-10 16:41:58 dirmngr[30976.6] http.c:RESP: 'Content-Security-Policy: default-src * data: 'unsafe-eval' 'unsafe-inline''
2019-07-10 16:41:58 dirmngr[30976.6] http.c:RESP: 'Strict-Transport-Security: max-age=31536000; includeSubDomains'
2019-07-10 16:41:58 dirmngr[30976.6] http.c:RESP: ''
2019-07-10 16:41:58 dirmngr[30976.6] DBG: (1624 bytes sent via D lines not shown)
2019-07-10 16:41:58 dirmngr[30976.6] DBG: chan_6 -> OK
2019-07-10 16:41:58 dirmngr[30976.6] DBG: chan_6 <- BYE
2019-07-10 16:41:58 dirmngr[30976.6] DBG: chan_6 -> OK closing connection
2019-07-10 16:41:58 dirmngr[30976.6] handler for fd 6 terminated

Seems gnupg requests the root of the specified server, for some reason?

The "http" or "https" schemes aren't specified for use with the keyserver command, so this is undefined behavior. What caused confusion with users for me was that there isn't an error about an unsupported scheme, and gnupg does do *some* network request, which led them to believe the URI was correct but something was wrong on the server. Is this intended behavior? If so, what are the semantics of http schemes in the keyserver config?

Valodim created this task.Jul 10 2019, 4:52 PM
Valodim created this object in space S1 Public.
tianon added a subscriber: tianon.Jul 10 2019, 4:58 PM
dkg added a subscriber: dkg.EditedJul 10 2019, 5:03 PM

aiui, a keyserver scheme of https:// implies that the specific URL is to be queried directly, not using any of the HKPS URL path patterns.

You'd typically use this when you know where a specific key is published, to say something like:

gpg --keyserver https://dkg.fifthhorseman.net/dkg-openpgp.key --recv C4BC2DDB38CCE96485EBE9C2F20691179038E5C6

or, like this:

gpg --keyserver 'https://keys.mayfirst.org/pks/lookup?op=get&search=0xC4BC2DDB38CCE96485EBE9C2F20691179038E5C6' --recv C4BC2DDB38CCE96485EBE9C2F20691179038E5C6

I believe this is derived from the preferred key server URL specified in RFC 4880, which does not embed any of the HKPS logic, but rather expects a single HTTP/HTTPS/finger/whatever URL that will be queried directly.

Ah, that makes sense, good catch. Seems this is just an issue of documentation, then.

@BjarniRunar suggested elsewhere to return a helpful error message if the root of some domain is used as a keyserver and no keys are returned:

$ gpg --keyserver https://keys.openpgp.org/ --recv-keys D4AB192964F76A7F8F8A9B357BD18320DEADFA11
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
gpg: warning: A "https" keyserver URI without a path is likely a configuration error. Did you mean: hkps://keys.openpgp.org
werner triaged this task as Low priority.Jul 15 2019, 8:16 AM