Debugging dirmngr (gpg --locate-key)

Werner Koch wk at
Fri Mar 29 13:04:00 CET 2019

On Fri, 29 Mar 2019 10:07, gnupg-devel at said:

> As far as I know this change, that requires strict path match was done
> to avoid a specific vulnerability.

Cross site request forgery.  The fear is that if you are on a site which
uses only IP based authentication to access internal services of your
site (e.g. a dedicated host to control the lightning of your building)
an attacker can control that internal service by sending you a redirect
to that host.  Your dirmngr would than contact that internal host and
access will be granted because the request comes from inside your own

I consider this quite far fetched but we better protect against this.  See

> Do you think it would be reasonable to put that requirement in the Web
> Key Directory [0] spec? This way other implementations can also be
> adjusted so that WKD works consistently across different software.

Yes, I think this is useful.

However, there is a second problem with They do not provide
the (possible empty) policy file.  This is a problem for two reasons:

If dirmngr looks up a key for one domain and does not find one, it will
test for the presence of the policy file.  If no policy file is found
either, further WKD request to this domain are not performed until a
restart of dirmnngr or until the domain is kicked out of dirmngr's hash
table with domain names [1].

Testing for domains supporting the web key directory does not work
because it is based on the presence of the policy file.

  $ gpg-wks-client --with-colons --supported
             ! !- Submitting keys supported
             !--- Lookup supported



[1] We still need to add time based removal of domains.

Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <>

More information about the Gnupg-devel mailing list