Needs testing (also for gpd5x) to understand the current state.

Reporter has tested 2.5 - the code in 2.2 is identical; no need for separate testing

I reworked the reading using our dedicated line reading functions which is used at other places. Extra benefit is that the code now also prints a status line ERROR which gives information on the first faulty line. Thus gpg-connect-agent listtrusted /bye can be sued to quickly check for errors without configuring a log file.

Without GpgsmCompatibility set and with the trust in the Root-CA established in the global trustlist file (the local one does not work for vs-complicane without GpgsmCompatibility=de-vs-trustlist , as expected), the compliance of a signature or decryption is now shown correctly and in accordance with the certificate status shown in Kleopatra. If the Root-CA is only trusted locally, the certificate and the signature are shown as "certified" resp. "not-compliant".
In short: everything works as expected if GpgsmCompatibility is not set.

auto-key-upload should not be triggered on revocation cert import, so everything seems fine.

Looks good to me on vsd-3.3.7-beta90.9 @ win10.

Note: Keyserver has to start with ldap: for this to work, otherwise it is silently ignored.

In general looks good to me on vsd-3.3.90.9 / gpg 2.2.54-beta4.

with GnuPG-VS-Desktop-3.3.90.9-Beta-Standard gpgsm now never shows the line [GNUPG:] VERIFICATION_COMPLIANCE_MODE 23. Therefore Kleopatra always shows "not VS compliant" now on verification and decryption. Even though the certificate is shown a VS-compliant in the list an when encryping:

gnupg22 received this patch meanwhile: rG7bc969d388086b4f3aeee3c5389b7baf055689d7

@werner I can confirm that we've tested the patch and it seems to fix the issue in our setup.

Applied to master to be release with 2.5.19.

2.2.53 was released wit VSD 3.3.6

But the original patch rG1b4ac98de7db: agent: Accept a trustlist with a missing LF at the end. was not working to allow missing newlines in gpg4win-5.0.0 @ win11?

That change is too complex for just getting a proper error message. The original patch covers the most common case.

This should also be fixed in 2.2 and 2.4 (if neccessary)

Has now been backported to be released with 2.2.53

It looks like we get a specific "Invalid public key algorithm" error from gpgme so that we can add helpful information with likely reasons to the error message.

I might add that we recently had a customer support contact where they had that error and asked how they could make using their S/MIME certificates work.

The behaviour might have changed a bit because of the ldap: prefix i use now, or i have missed this case the last time:
Given some cert on the "download" server, I can find it, if dirmngr.conf contains only the "download" server, or if the "download" server is listed first:

Independent of keyserver order in dirmngr.conf, --search-keys still offers keys from the upload server, but the download fails:

For "Although the upload server is used for upload, the gpg message still displays the first keyserver" see T8025

That was fixed with 2.2.52 which fixed a bug in the fix done in 2.2.50 (see rG31fef13df1). Note that 2.2.48 to 2.2.50 had only internal releases.

The problem was the keyserver configuration, which does not include a scheme (ldap:):

keyserver ldap.gnupg.test:389:uid=LordPrivySeal,ou=GnuPG Users,dc=gnupg,dc=test:pass:dc=gnupg,dc=test:

Well, I tested this again. I created a new key and saved a copy. The I updated the expiration date to 2035 and sent the key to the LDAP server. Then I deleted the updated key locally and imported the old copy. Thus I have now:

we haven't seen this in a while…

This seems not to work in Kleopatra/gpg in gpg4win-5.0.0-beta413 @ win11.

Tested on gpg4win-5.0.0-beta413 @ win11 with the following entries in dirmngr.conf:

meanwhile it looks like this in Kleopatra, it has now the blue sign but the issue is still the same: