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.

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:

Here is my attempt for fixing the de-vs compliance check when verifying a signature:

Not a good idea. Because then the user will open it with the browser and the browser loads all kind of additional data including drive-by malware. If HTML *mail* is shown by a MUA no links should be followed to keep information and the fact that it was read confidential.

I put the new menu entries below the menu entry for the Quick Guide into the Help menu.

Done. And backported for VSD 3.4.

Note: I noticed that most of the old documents use underscores instead of hyphens in the document names. It doesn't really matter, but being consistent makes it easier to avoid typos.

In vsd 3.3.6 the option is now greyed out.

Marcus suggestion: offer the HTML mail content as attachment.

Looks good to me on gpg4win-5.0.2-beta2 @ win11.

• local conf after 2 saves (additional entry in local conf):
  
• local conf after 2 saves (additional entry in global conf):
  

Is this still a requirement?

Looks good to me on gpg4win-5.0.2-beta2 @ win11:

Looks good to me on parallel install of

1. gpg4win-5.0.2-beta2 @ win11
2. vsd-4.0.0-beta1203 @ win11

The workaround is ready for testing. Kleopatra shouldn't show duplicate LDAP servers in the settings dialog. As a side effect global ldapserver entries should no longer multiply in the local dirmngr.conf each time the LDAP servers are changed, but one copy of the global ldapserver entries is still written to the local dirmngr.conf.

The fix is only a workaround, the duplicate entries are no longer shown in Kleopatra, they still exist and multiply on save.

One doesn't even need a global config file to reproduce the duplication.

This ticket is now obsolete, as we will force the setting of autoencryptUntrusted=0 via the registry in Ticket T8090

This ticket is only for ignoring the autoencryptUntrusted setting. For the gpgolconfig.exe part see T8090

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.

Backported for VSD 3.4

Fixed. Kleopatra now looks for programs given as plain name (i.e. without any path) first in the GnuPG installation path (as reported by gpgme) and then next to the kleopatra executable. If the program is found at neither location it is run as-is.

a) Here's a log anyway (ignore it, if decryption does always work):

We'll go with solution no 2 (which is in effect the same as no 1 anyway)

a) Info given by @mmontkowski: decryption can't be disabled

Backported for VSD 3.4

Done. Example (with default text in English and German translation):

[Welcome]
welcome-text[$i]=<h2>Hello, World!</h2>
welcome-text[$i][de]=<h2>Hallo, Welt!</h2>

testing with 2.5/2.6 will wait for special build

Given that the 2.2 fix has been tested and resolved and we don't have another ticket for 2.6, we can close this one.

works in Gpg4win-5.0.0-beta476

If no logging is running in the background (that's something that often trips me…) on consecutive runs:

Indeed. We would need to add different entries to the context menu for each installation. Given that GpgEX needs to be replaced anyway and we will drop the need for a UI server socket (which is anyway only a trigger and no full communication).

Fixed and backported for VSD 3.4.

Ranking as discussed with @ebo

The root cause is that opening the details reloads the certificate. This triggers a change of the key cache. And that triggers are reload of the group.