If the user clicks the "No, others also use this key" button they get the following dialog

You are totally correct, confirmed with VSD 3.3.5.

I was curious: Similar to the kiosk/immutable feature of kconfig, gpgolconfig allows to flag values as immutable by appending a '!' to the value set in the registry. If autoencryptUntrusted is set to 0! via the registry then the checkbox should be disabled.

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

@werner: Shall we backport the fix to the gpgme-1.24-branch or do we just add a patch to gpg4win's gpg4win-4-branch and/or vsd-3.3-branch?

I have verified (by locally applying the change to a Gpg4win 4 build) that ifdef'ing-out the above hack for Windows builds fixes the display issue.

To test in gpgol after the fix (see T7836: GpgOL: Both disable and prefer S/MIME does not work):

1. Make sure you have both secret openpgp and smime certs for ted (both split S/MIME keys)
2. Deactivate "Always show security approval dialog"
3. Enable S/MIME and activate "Prefer S/MIME"
4. Kill background processes and restart Outlook (just to be sure)
5. Send an encrypted/signed mail form and to ted => should be S/MIME encrypted

Merged

Merged

The capping of the date seems to be caused by this workaround/hack in gpgme's _gpgme_parse_timestamp

/* Fixme: We would better use a configure test to see whether
   mktime can handle dates beyond 2038. */
if (sizeof (time_t) <= 4 && year >= 2038)
  return (time_t)2145914603; /* 2037-12-31 23:23:23 */

The problem resulted from a split up key (one for encryption and one for signing) Resulting in no SMIME encryption key found for one recipient and thus falling back to OpenPGP.

Now an expired signature with certified key is reported like this:

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.

The blue Kleopatra icon is now used for the Windows builds of Gpg4win and GPD and for the corresponding AppImages.

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.

Initial version in work/tfry/trustlevel.

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.