Page MenuHome GnuPG
Create Task
Maniphest T7537

WKD key import denied due to false dirmngr caching
Closed, ResolvedPublic
Actions

Description

Abstract
WKD key import does not import existing keys due to dirmngr caching information for non-existing keys.

Versions
2.5.4 Upstream and 2.2.40 Debian/Devuan

Situation
Assume there is no key for alice@example.net via WKD published, but there is one available for bob@example.net via WKD. The domain parts are equal.

Try to import from the command line (output stripped to important parts):

$ gpg -v --locate-external-keys alice@example.net
gpg: error retrieving 'alice@example.net' via WKD: No data
$ gpg -v --locate-external-keys bob@example.net
gpg: Note: WKD uses a cached result
gpg: error retrieving 'bob@example.net' via WKD: No data

This has got several implications:

  • it appears to be a client self DoS
  • UX interference in interactive mode, hard to understand
  • any setup with batch key import will probably fail starting from the first non-existing key

Mitigation
A user can kill the dirmngr process. Then a key import for bob@example.net works again.

Details

Version
2.5.4

Event Timeline

fmg created this task.Thu, Feb 20, 3:29 PM
fmg added a comment.Fri, Feb 21, 12:08 AM

Reproducibility
The problem cannot be confirmed generic on domain level. I can reproduce the effect with keys shipped from my domain, i.e. email addresses @shimps.de, but the issue vanishes when I try to reproduce it with email addresses @gnupg.org as e.g. Werner's address.

I used https://www.webkeydirectory.com/ to investigate and compare the setup. The main difference I observe is that I use the version with third level domain openpgpkey only (advanced method but not direct method).

The influence of webserver setup and configuration on the occurence of the problem needs further investigation.

• werner triaged this task as Normal priority.Fri, Feb 21, 9:00 AM
• werner added a subscriber: • werner.

The caching works on the base of the requested domain, that is example.org and not openpgpkey.example.org - thus it should not make a difference when you change your setup. There is an initial test for a cached domain status before the resolving process starts. If you want to look yourself: gnupg/dirmngr/server.c:cmd_wkd_get() and domainfo.c.

dirmngr has quite some logging which youy may want to enable. My suggesting for testing is to put
"log-file socket://" into dirmngr.conf (or common.conf to cover all daemons) and to run watchgnupg in a different tty. To enable specific debug options for dirmngr, run "dirmngr --debug help" . At least a "verbose" in dirmngr.conf is always a good idea.

"gpgconf -K dirmngr" is the suggested way to clear the dirmngr caches by restarting it (gpg will start it again on demand).

A useful test command is for example

$ gpg-wks-client check -v --debug ipc torvalds@kernel.org
gpg-wks-client: DBG: chan_3 <- # Home: /home/wk/.gnupg
gpg-wks-client: DBG: chan_3 <- # Config: /home/wk/.gnupg/dirmngr.conf
gpg-wks-client: DBG: chan_3 <- OK Dirmngr 2.5.4-beta11 at your service, process 10783
gpg-wks-client: DBG: connection to the dirmngr established
gpg-wks-client: DBG: chan_3 -> WKD_GET -- torvalds@kernel.org
gpg-wks-client: DBG: chan_3 <- S SOURCE https://kernel.org
gpg-wks-client: DBG: chan_3 <- S PROGRESS tick ? 0 0
gpg-wks-client: DBG: chan_3 <- [ 44 20 99 01 25 30 44 04 4e 79 08 92 01 08 00 a4 ...(252 byte(s) skipped) ]
[...]
gpg-wks-client: DBG: chan_3 <- OK
gpg-wks-client: DBG: chan_3 -> BYE
gpg-wks-client: public key for 'torvalds@kernel.org' found via WKD
gpg-wks-client: fingerprint: ABAF11C65A2970B130ABE3C479BE3E4300411886
gpg-wks-client:     user-id: Linus Torvalds <torvalds@kernel.org>
gpg-wks-client:     created: Wed 29 Nov 2017 09:31:15 PM CET
gpg-wks-client:   addr-spec: torvalds@kernel.org
gpg-wks-client:     user-id: Linus Torvalds <torvalds@linux-foundation.org>
gpg-wks-client:     created: Tue 20 Sep 2011 11:41:38 PM CEST
gpg-wks-client:   addr-spec: torvalds@linux-foundation.org

The debug option shows the actual communication with the dirmngr. You may issue the command yourself using "gpg-connect-agent --dirmngr". The source line shows the actual URL used (try my mail address to see the openpgpkey prefix used.

fmg closed this task as Resolved.Fri, Feb 21, 5:05 PM
fmg claimed this task.

New Situation
Once I started testing in logging mode the problem had gone away already. There were some hints to HTTPS certificate issues, but nothing really to blame. Neither with nor without logging the problem could be reproduced after two days of questioning me.

Solution
A few months ago I started WKD following this howto
https://www.kuketz-blog.de/gnupg-web-key-directory-wkd-einrichten/
which describes the direct method while I assumed to setup advanced method following different howtos as well.

Recently the webchecker for WKD
https://www.webkeydirectory.com/
showed me the file policy not being at the correct place which I corrected. Thus the problem was gone this morning.

Confirmation
I confirmed this behaviour with another domain of mine, where the problem vanished immediately when policy was fixed.

Conclusion
This was a PEBKAC problem, but extremely difficult to trace to its origins due to normal testing methods. To set this up, to notice it and to solve it were like a chain of coincidences.