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.

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

The "ca" root cert is not on the ldap, if that matters

In T8048#211860, @ikloecker wrote:

some other certificates, but I guess those are from other tests

It also happens on CLI:

With Gpg4win 5.0.0 the LISTKEYS after the server lookup lists the (ephemeral?) ca@gnupg.test certificate and (!) the bob@gnupg.test certificate (and some other certificates, but I guess those are from other tests).

1. VSD 3.3.4

1. Gpg4win 5.0.0

• gpg4win 5.0.0 @ win11

gpgme logs (also of vsd-3.3.4) will be useful.

I have not checked but I guess that the certificate is marked as ephemeal and kleopatra either lists ephemeral certificates or the ephemeral flag got removed to to a validation process,

Note: This does not happen on vsd-3.3.4

See the gnupg-devel mailing list for more discussions. Subject: libgcrypt P256 signature malleability via weak DER enforcement"

Some historic integer encoding glitches from Peter Gutmann's style guide:

in Gpg4win-5.0.0-beta479

Traditionally we have considered expired and revoked more or less similar. The idea is that an expired key might have been compromised but the owner did not found a way to revoke it. We may want to change this policy because some users don't care too much about expired keys (cf. T7990) .

How does gpgsm react if you try to sign with the certificate?

Maybe it would be better to just not offer S/MIME certs with distrusted root cert?

If all processes are killed before okular is opened, i get an error on "finish signing":

gpgsm.log (debug-all, whole process of signing)