I applied the keyboxd part for SETEPHEMERAL command, as it doesn't break anything.

Here is an attempt to fix the client side:

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.

This is a regression that was introduced with T7759: Kleopatra: Notepad encryption with S/MIME fails.

Fixed. For VSD 3.4 this will also be fixed if gpgme is updated.

This is a bug in gpgme. gpgsm_assuan_simple_command only reads a single line before waiting for more data although there is a second line (ERR ...) ready to be read. gpgsm never sends more data because it has already sent its full answer. So gpgme waits forever.

I looked at sm/keydb.c:keydb_set_ephemeral function. It says:

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

It seemed that the reporter (also) claimed that a git repo could be weak/vulnerable when X.509 signature (with a relevant curve key) is used to validate the commit.

For the record (to show we don't hide a problem), I add some information.

Backported for VSD 3.4

Done.

ok, lets do this. I'll update the description

I'm fine with just dropping it.

Do we agree to drop bolt font for QES certificates?
Will we change this for VSD 3.4?

Okay, then I set the ticket to Testing.

Your fix is okay.

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

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.

The display in Okular is independent from Kleopatra, so dropping it in Kleopatra should be fine.
If a QES certificate is available, Okular should highlight and add a filter for them (which is currently not working, see T6632: Okular: Highlight / preselect "nonRepudiation" certificates for qualified signatures)

I currently have a slight preference to drop bold and go with normal font. Werner would be ok with that, too.

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

@svuorela said, QES certs shouldn't be required to be on a smartcard.

Using an icon for QES certificates isn't that easy because we use an icon for smartcard certificates and any list item can have at most one icon. Moreover, QES certificates are very like stored on a smartcard (isn't that even a requirement?), i.e. an icon clash is basically guaranteed.