I guess the test fails because one cannot create a key with an expiration date before the current date. And the test tries to create a key which expires on 2038-01-01 which will fail if the test is run on 2038-01-01 or later. The easiest fix would be to disable the test cases if the current date is past 2038-01-01.

Okay, then I set the ticket to Testing.

Unfortunately, this was run on x86_64 and also other 64 bit archs.

Is that on a 32 bit machine or 64? The latter would be a problem for 32 bit with 32 bit time-t I'd say: we won't fix it.

At least for an expired data signature I would suggest to have an info button to further expliah this. Maybe to a FAQ or KB article. The case is too rare that we should not discuss endlessly the pros and cons of expiring signatures. I hope that Kleo does not provide an option to crerate such a signature.

Sorry for the ambiguity. The request was only about mentioning (bpX) for the first two choices, not to add more combinations.

Your fix is okay.

AFAICS all conditions are protected by isascii(3) which

Physical experiment feature support should better not be widely used.

Although it is technicall possible to use all combinations, we should limit in the menu them to those as listed above. Too many algorithms pose an interop problem. Thus we provide brainpool because it is required in Germany and the two IETF curves for the general internet (for those who are playing mitigation against against physical experiments).

After serveral clever attempt, I've settled to this simple workaround that seems working despite being quite inefficient: if you don't find any key with gpgme_op_keylist_next and gpgme_err_code(err) == GPG_ERR_EOF on a ctx with keylist mode set to GPGME_KEYLIST_MODE_LOCATE, try again (even on the same context), after

Looking to workaround this issue, I've noticed something that might be useful during debug.

Note: In vsd it must be restricted to the bp algorithms then

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 */