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.

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

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

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:

2.2.53 was released wit VSD 3.3.6

I have added the fix as patch for VSD 3.3 because the commits that introduced this regression were also added as patches for VSD 3.3.

config file: Sorry, I got confused, it has to be %APPDATA%\GnuPG VS-Desktop\kleopatrarc in this case (VS-Desktop-4.0.90.1203-Beta), of course. And this one works.
Registry entry SOFTWARE\GnuPG VS-Desktop\Kleopatra\CMS\SaveCSRAsPEM does not work, though. But this is a separate issue, seems all Registry entries do not work in that build.

• config file: According to T7717: Location of qt-application config files %APPDATA%/Gpg4win/kleopatrarc should work.
• registry: According to T5707: Kleopatra: Use windows registry additionally to config files this should be SOFTWARE\Gpg4win\Kleopatra\CMS\SaveCSRAsPEM now

Works with VS-Desktop-4.0.90.1203-Beta when putting this in C:\Program Files\GnuPG VS-Desktop\share\kleopatrarc
CSR is then saved as .pem file with ascii-armored content.

Also backported for VSD 3.4.

Now also available in Gpg4win 5.

Ready for testing in VSD 3.3

What about always using PEM for all generated CSRs? As far as I can see, gpgsm command line always uses PEM when generating CSRs.

Test with beta32

VS-Desktop-3.3.90.31-Beta shows no warning any more for the export of a newly generated key.

So this means, the order in the description should be implemented, right?

Yes, by definition an immutable group doesn't allow any changes for that group. Don't mark a group as immutable if you want to allow changes.

The [KDE Action Restrictions][$i] in XDG_SYSTEM_DIRS/kleopatrarc prevents any changes within the whole group afterwards.
I guess, this is intended by defining an "immutable group", but i doubt that we want to prevent admins to change those settings?

So, regarding the minor version change: the change of order seems not critical (as there was no settings file before), but the introduction of the settings file might be.

I verified, that both in vsd 3.3.2 and vsd 3.3.3 beta90.29 the current implementation is

And we shouldn't change the precedence in a minor release, I believe.

The configuration readout order still needs to be specified/fixed.

Looks good to me on vsd-3.3.3-beta90.29 @ win11