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) "Prefer S/MIME" only applies to encryption, not decryption. If you do not want to decrypt with GpgOL you have to disable S/MIME in GpgOL.

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).