Can you do a search on the command line:

gpg -v --search-keys foo@example.org

Apologies for the delay here, but the particular user claimed it was no longer an issue and it fell off my radar. However I now have a new individual with the same problem.

Again it's quite odd as a key actually is returned, it just first shows the error and then the returning key appears.

This also occurs on 4.0.3.

The first screen cap is the error, then if you click OK the key populates as soon in the next window. I also have a screen cap attached of the CLI as requested and this pulls without warning/issue.

Kleopatra does searches in parallel. What you see in the second dialog might be a response from a Web Key Directory (i.e. search by mail address with lookup at the mail domain).

OK, so this warning should just be ignored then?

In T6014#163001, @ebeiersdorfer wrote:

OK, so this warning should just be ignored then?

No. I think Werner just wanted to explain why a key appears to be found even though an error is reported. The keyserver lookup fails, but the WKD lookup succeeds. If the latter finds the key you are looking for then you can ignore the error. But, of course, there shouldn't be a "Syntax error in URI" error in the first place.

Ah OK I'm following now, I had took that as maybe another lookup at that time was failing. The keyserver that we have configured is hkps://keys.openpgp.org. Is there any misconfiguration here with that setting?

To debug this you can enable logging of the dirmngr (which does actually talk to the keyservers). To do so open GnuPG System/Network in Kleopatra's configuration dialog and set the debugging level to 4 - All and enter a filename for the log file.

Looking up "foo" and "foo@example.net" I got no results and the following in the logs:

dirmngr[30176.5]: error accessing 'https://keys.openpgp.org:443/pks/lookup?op=index&options=mr&fingerprint=on&search=foo': http status 400

and

dirmngr[30176.8]: error accessing 'https://keys.openpgp.org:443/pks/lookup?op=index&options=mr&fingerprint=on&search=foo%40example%2Enet': http status 404

but no "Syntax error in URI" error.

Note that there are two different places to set the keyserver: dirmngr.conf (preferred) and gpg.conf (deprecated). For backward compatibility the option in gpg.conf is preferred over the option in dirmngr.conf. With recent versions of gpg (and Kleopatra) Kleopatra will show the keyserver that is actually used on the Directory Services page of the configuration dialog, but for older versions it may not show the keyserver that is actually used. So you better double check the keyserver option in gpg.conf and dirmngr.conf and remove the one in gpg.conf.

So looking through the logs it appears that it is trying a lookup against our domain, in addition to the key server we have configured.

dirmngr[8556]: URL 'https://<domain>.com/.well-known/openpgpkey/hu/enzdc18iy17uy9qb3pwm4ay9a1ga6mb3?l=<user>' redirected to '/.well-known/openpgpkey/hu/enzdc18iy17uy9qb3pwm4ay9a1ga6mb3/' (301)
dirmngr[8556]: command 'WKD_GET' failed: Syntax error in URI

I messed around with some settings and couldn't get this disabled, is there a way to disable this that I'm missing?

There is probably an umlaut or special character in <domain> or <user> which makes the URL invalid. If I search for "test@ä.de" I also get Syntax error in URI.

I think it is problematic that the WKD errors are shown to the user at all. Doing some random searches gives an error each time something can't be accessed.

In T6014#163083, @aheinecke wrote:

I think it is problematic that the WKD errors are shown to the user at all. Doing some random searches gives an error each time something can't be accessed.

Can you give an example other than the Syntax error issue? So far, I haven't seen any errors when doing random searches with ASCII-only "email addresses". I simply get zero results, but I don't see error messages, e.g. if the host cannot be found.

Let me know if you want full logs, but here is the segment with more info.

dirmngr[8556]: URL 'https://ltvco.com/.well-known/openpgpkey/hu/enzdc18iy17uy9qb3pwm4ay9a1ga6mb3?l=jtlynch' redirected to '/.well-known/openpgpkey/hu/enzdc18iy17uy9qb3pwm4ay9a1ga6mb3/' (301)
dirmngr[8556]: command 'WKD_GET' failed: Syntax error in URI
dirmngr[8556]: DBG: chan_0x00000480 -> ERR 167772206 Syntax error in URI <Dirmngr>

Seems like anything against our domain (we typically upload keys username@ltvco.com) fails like this.

Does dirmngr maybe interpret the redirect reply /.well-known/openpgpkey/hu/enzdc18iy17uy9qb3pwm4ay9a1ga6mb3/ as URI? That would explain the error because without protocol the redirect reply is indeed an invalid URI.

Now the question is: Is dirmngr not interpreting the redirect correctly? Or does ltvco.com reply with an invalid redirect?

Using curl I am redirected first to https://www.ltvco.com/.well-known/openpgpkey/hu/enzdc18iy17uy9qb3pwm4ay9a1ga6mb3?l=jtlynch and then to /.well-known/openpgpkey/hu/enzdc18iy17uy9qb3pwm4ay9a1ga6mb3/ which is a relative URI-reference that is valid according to https://www.rfc-editor.org/rfc/rfc7231#section-7.1.2 and https://www.rfc-editor.org/rfc/rfc3986#section-4.2.

It seems that dirmngr lacks support for relative redirect URI-references.

That's for sure. See rGfa1b1eaa4241ff3 :

dirmngr: Avoid possible CSRF attacks via http redirects.
[...]
With this change a http query will not follow a redirect unless the
Location header gives the same host.  If the host is different only
the host and port is taken from the Location header and the original
path and query parts are kept.

Of course it could be refined to use the same host if there is only a relative URL.

In T6014#163086, @ikloecker wrote:

In T6014#163083, @aheinecke wrote:

I think it is problematic that the WKD errors are shown to the user at all. Doing some random searches gives an error each time something can't be accessed.

Can you give an example other than the Syntax error issue? So far, I haven't seen any errors when doing random searches with ASCII-only "email addresses". I simply get zero results, but I don't see error messages, e.g. if the host cannot be found.

For example "foo@x500.bund.de". But what I meant is that code handling WKD errors that show an information to the user should not exist. All WKD lookup errors in Search should be silently discarded. Because the user does not know that he is performing a WKD search so she should not be informed about errors in that.

I have created the spin-off T6202: Kleopatra: Suppress errors of WKD lookups to deal with not bothering Kleopatra's users with error messages when doing a WKD lookup in the background. This task is for improving dirmngr.

I just want to point out that we wouldn't have noticed the lack of support for redirects with relative URIs in dirmngr if the "Syntax error in URI" error wouldn't have been reported by Kleopatra. It's probably still sensible to hide such errors from the users because the majority won't be able to do anything about them.

Awesome, thanks all! From an end user perspective that would be a perfectly acceptable outcome, the warning just serves to confuse people. Appreciate the help!