Thank you for the bug report and your patch.

An update FYI

Fixed by changing server as noted above.

Thanks for all the help @gniibe.

It should not be removed as I believe it is required to be compliant:

I'm afraid that your particular configuration would cause the problem of the negotiation.

Note that we now have also an option instead of the workaround from 2015

For various reasons dirmngr requires and implements a full resolver and implements that. This way all DNS queries are passed through Tor. Thus this is a feature and not a bug. The error message could be better but we can only return what SOCKS tells us.

Lot's of things changed in the meantime.

HKP keyservers are anyway out of fashion and thus we won't put anymore effort into his part of the code.

Lot's of changes since 2.4.

See for T6545 for a new request to support IDP.

I have now disabled the rewriting in the 2.4 branch. Those who want to keep the old behaviour may add

I will review the issue. A likely outcome will be to follow your suggestion but to add an option for the old behaviour to avoid further security discussions.

After diligently reading the code I realized that this bug has long been fixed. For reference here is the patch I wrote to extend dirmngr_ldap during my tests:

This has been solved loooong ago.

We need to extend dirmngr_ldap.c to take a list of attributes to return. We already have the --multi option which returns all attributes for latter filtering by the caller but the specified attr is also used and thus dirmngr's start_cacert_fetch_ldap() retruns only the requested caCertificate.

Hello All,

The code has meanwhile been reworked and the mentioned test server is not anymore available

Applied and pushed the change from @joeyberkovitz in rG3257385378bb: dirmngr: Interrogate LDAP server when base DN specified..

BTW, I have also in mind to use an AD entry to figure out the used keyserver. It turned out that people don't like to modify the schema of their AD but instead use a separate LDS.

To proceed, I pushed an initial part as rG993820c31521: dirmngr: Factor out interrogate_ldap_dn function., which doesn't change any behavior.
Then, the point of the change will be clearer.

What is a partial CRL; I have never seen that and IIRC the specification for that was not complete.

For what it is worth, I think that my patch is more standard compliant then yours because it checks if there is a partial CRL.

I think 289fbc550d18a7f9b26c794a2409ba820811f6b3 implemented this wish from 2016 :) @werner please read the full report and then close it as fixed if you agree. I find it a bit funny that we both came independently to the same conclusion, that it should be handled differently even if the standard says otherwise. Because the behavior from the standard does not make sense and is in contradiction to other parts where it says that each CRL must contain all revocations.

just checking in about getting this patch reviewed

That particular bug seems to have been solved a long time ago. I stumbled upon up while fixing a DP bug today.

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!

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.

The fix has been merged to the 2.2 branch.

In T6067#160368, @vitusb wrote:

Due to https://dev.gnupg.org/T5725#153224 ("The fingerprints are needed by Kleopatra as unique identifier for keys."), is this still implemented in that way ?

What i don't understand is ...

Due to vacation the review may take some time.

It will hopefully be fixed in 2.2.37.

Hello,
thanx for fixing this issue ...

Any chance someone is able to review the posted patch?

Let me know how best to submit it

I tried to submit the below patch to gnupg-devel@lists.gnupg.org, but get an Unrouteable address error. Let me know how best to submit it

The first ideas sounds best to me. Patches please to the mailing list.

Was fixed in 2.3.5

We have not seen this problem anymore in recent versions. Thus closing.

We have a solulion for this bug. For further improvements we will use T5882.

Good idea. Thanks. Goes onto 2.3 and 2.2

Confirmed to work, thanks!

it still shows the no certificate or invalid encoded error message:

I gave it a try. It works now, but it still shows the no certificate or invalid encoded error message:

Thank you. Confirmed.

Actually this is pretty obvious; we better ignore such misbehaving servers.

I think that the particular issue of Let's Encrypt Certificate was handled correctly already.