In T7455#211913, @ikloecker wrote:

In T7455#211465, @timegrid wrote:

Issues found:

• The "Finish" button in the "Sign/Encrypt" dialog turns to "Sign/Encrypt" sometimes after successful execution:

I've seen this at least once. No really related to this ticket, but I'll have a quick look.

The first time Okular was included is gpg4win-4.2.0:

See here for how it should look like:

• https://invent.kde.org/graphics/okular/-/merge_requests/1120
• https://invent.kde.org/graphics/okular/-/merge_requests/1121

I see. I added the root cert to C:\ProgramData\GNU\etc\gnupg\qualified.txt and the usage of the signing certs does include a qualified signature in Kleopatra now. Still I don't see any highlight/filter in Okular:

In T7455#211465, @timegrid wrote:

Issues found:

• If pgp is preselected, the "Sign..." operation will also check "Encrypt for others":

setting to High as we need this for T7790

Implemented and backported for VSD 3.4

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

Fixed and backported for VSD 3.4

None of these certificates are for qualified signatures.

Try compare with a gpg4win 3.latest.

I have this fix committed to my working directory:

We have no CVE yet. However, CVE is also a good tag for security bugs,

I create diff with implementation via VirtualLock WinAPI: https://dev.gnupg.org/D622

On 2026-01-20, I found the message to security@gnupg.org of:
Message-ID: 4e708880-04ac-45bc-8d16-6b585f2652a1n@aisle.com
in may spam folder. It has a 10MB long attachment. That might be one of reasons to be identified as a spam.

Considering the current implementation (tpm2d doesn't support keyinfo like scdaemon), it would be good to check the buffer size.
(If key information is accessible easily, we can check with a specific key.)

The gpgme logs show that the information for revoked keys should be there. We just need to check for it (and somehow visualize it).

pub:o:3072:1:3DA05D6B0A5998AF:1768822823:1863514800::::::::
fpr:::::::::C70F6D8F32DFE96F5C47C40B3DA05D6B0A5998AF:
uid:o::::::::search (valid) <search@gnupg.test>\r:

gpgme.log (vsd 3.3.4):

Fixed. The problem was that the selected sections were stored in the 64-bit registry (unless browser integration was installed; see T8038), but they were read from the 32-bit registry.

Fixed.

Let's give this Normal priority.