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 is used to validate the commits.

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.

In T6632: Okular: Highlight / preselect "nonRepudiation" certificates for qualified signatures I had the impression, that some hint is useful for signing operations. Probably not so much in general.

Highlighting QES is mostly useful for Okular, I guess.
Maybe use a symbol with a pen? That should be self-explanatory.

This overloading of "bold" for "my certificates", "qualified certificates" and "trusted root certificates" seems to exist since two decades. I stopped digging into ancient history at the commit that added the hard-coded default filters.

Take care: Too many attributes (color, font) are bad style.

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

Well, the qual flag should only be set for CAs dedicated to certifying QES certificates. And those should by definition be signature certificates only, afaik.

Ah, thanks for the pointer, I did not expect gpgsm to behave differently here. Then it's probably intentional and I'll close this as invalid.

The gnupg manual (page 113) mentions:

Current state in gpg4win-5.0.0:

There's no other configuration, this happens with a clean gnupghome with one smime cert + root cert and the above gpgsm.conf (output on stdin/stderr):

Please run with --debug 0 which should show you which confiration files are read in which order. Is there anything in a common.conf file? A log-file statement tehre would overwrite the command line option.

setting to High as we need this for T7790