I guess that the missing formatting of fingerprint or key ID isn't restricted to v5 keys. -> separate ticket

In T7345#202503, @timegrid wrote:

• Some/Most "Not VS-NfD compliant" notes do not have the (beta) suffix (probably fine?)

Ingo tested this and it worked.

Looks good to me on gpg4win-5.0.0-beta336 @ win10:

• Full stops are fine now
• "not VS-NfD compliant" for invalid signatures not shown anymore (tested in vsd compliance mode)
  

Looks good to me on gpg4win-5.0.0-beta336 @ win10.

Looks good to me on gpg4win-5.0.0-beta336 @ win10.

Looks good to me on gpg4win-5.0.0-beta336 @ win10:

Looks good to me on gpg4win-5.0.0-beta336 @ win10.

With above configuration it seems to work on gpg4win-5.0.0-beta336 @ win10.
Any way to verify in kleopatra, that the setting was applied?

Tested on gpg4win-5.0.0-beta336 @ win10.

Looks good to me on gpg4win-5.0.0-beta336 @ win10.

Looks good to me on gpg4win-5.0.0-beta336 @ win10.

Looks good to me on gpg4win-5.0.0-beta336 @ win10.

Looks good to me on gpg4win-5.0.0-beta336 @ win10.

Looks good to me on gpg4win-5.0.0-beta336 @ win10.

Looks good to me on gpg4win-5.0.0-beta336 @ win10.

Looks good to me on gpg4win-5.0.0-beta336 @ win10.

Looks good to me on gpg4win-5.0.0-beta336 @ win10.

I tested the VSD elements on gpg4win-5.0.0-beta336 @ win10 (beta compliance mode).

Happens also in the group config (warning icon):

Looks good to me on gpg4win-5.0.0-beta336 @ win10.

One screenshot of the test setup for reference:

Mostly looks good to me on gpg4win-5.0.0-beta336 @ win10/win11.

Related? In smartcards view:

Shouldn't the enabled close button in win10 / disabled text / nr2 have green color? (it's the "search certs on server" dialog).

This also happens on Linux. And even with the Fusion style.

Thanks for the Windows 11 screen shots.

We decided to only add a green check mark (or red X in case it fails) on the left side in the message frame.

Thanks for the feedback. The issues are the same as on win10:

After discussion with Ingo and others it seems that separate Kleo processes per GNUPGHOME would confuse more users than being helpful for power users. Considering the use case of gpgpass the conclusion was to add an option to Kleo which allows to start is as a certificate manager without doing the UniqueApplicaiton thing and also entirely quit after closing the window.

Regarding the "unsure" findings:

• invalid state in cert list tooltip (red on black)

1. Issues found

What about including the output of

On gpg4win-5.0.0-beta330 everything works fine again (both smime and openpgp regardless of expiration).

I now imported all certs in testzertifikate_2023/ (smime and openpgp) and generated a new one (openpgp, default settings, expiration 2028) and still get no valid signing certs in okular

added gpgsm log:

Ingo mentioned some maybe related expiration year 2038+ ticket, but I only found one for kleo: https://dev.gnupg.org/T7069

Issue about no valid smime certs found on signing split into: https://dev.gnupg.org/T7697

This is more a technical ticket. There's not really something to test. Setting to Resolved/Done as discussed with ebo.

Note that the first screenshot shows still "Sign/Encrypt" as button text instead of "Finish", but I didn't notice that again after this

Most issues with icons in high contrast modes (of Windows 10) should have been fixed. Needs to be verified especially with the high contrast modes of Windows 11.

Setting to Testing.

Moving to QA. All changes should be in the latest beta.

Many issues have been fixed. Setting to Testing to check what I have missed.

3 non-hang logs, all took ~20s to open the file (with 20s "Keine Rückmeldung" shown in Okular)

The problem with the invalid certificates seems to be unrelated. Isn't there already a ticket for Okular for certificates which expire after 2038?

If keyboxd sometimes takes 6 seconds, then I'm not surprised that stuff times out after 8 seconds occasionally. Or well. we need more numbers to determine that.

And in the first case, about 6 seconds are lost starting keyboxd:

2025-06-23 13:16:55 gpgsm[3252] DBG: chan_0x000000000000022c <- VERIFY
2025-06-23 13:16:57 gpgsm[3252] Kein aktiver keyboxd - `C:\\Program Files\\GnuPG\\bin\\keyboxd.exe' wird gestartet
2025-06-23 13:16:59 gpgsm[3252] Warte bis der Keyboxd bereit ist ... (8s)
2025-06-23 13:17:01 gpgsm[3252] DBG: chan_0x0000000000000260 <- # Home: C:\Users\g10\AppData\Roaming\gnupg
2025-06-23 13:17:01 gpgsm[3252] DBG: chan_0x0000000000000260 <- # Config: [none]
2025-06-23 13:17:01 gpgsm[3252] DBG: chan_0x0000000000000260 <- OK Keyboxd 2.5.6 at your service, process 4748

Here's the gpgsm debug log (debug x509,ipc,lookup):

The keylisting hangs ticket for Kleopatra: T6623

In T7658#202206, @svuorela wrote:

@ikloecker is https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=commitdiff;h=f23cef6f66a44c5c1cc8717f74b658d14fde04e5 needed to be forward ported to split gpgmepp ?

@ikloecker is https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=commitdiff;h=f23cef6f66a44c5c1cc8717f74b658d14fde04e5 needed to be forward ported to split gpgmepp ?

It could be connected to those "keylists hangs" problems. On Kleopatra it took some time to refresh the key list. After that I can open the signed file again.

Well, now I also can reproduce the hanging on verification again (opening of an unsigned document is fine, of a signed document hangs).
Maybe the signing part above is important to trigger it - although it happened now in a clean state after a reboot, so it should not be caused by e.g. leftover processes.

I'm quite sure, that I used a fresh install on a new VM, but on another fresh one I can't reproduce the verification part anymore and the signature is shown as valid.