1. Issues found

But we have the same problems on Unix as described by T7699. (funny, the other bug mentioned above has 76 reversed)

This will never happen on stock Linux.

We decided to keep the color white for these cases and only add some further information, see T7701: Draft: Kleopatra: Add information for verification results

I know of no current Linux issue with this, I thought only the MSI installer is affected

That is not Windows specific. They should end up in %GNUPGHOME%/kleopatra/

What about including the output of

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

Should current behavior of 'starting with no arguments' be preserved? or should we add a --generate or --doit or similar ?

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.

Fixed in 2.5.8.

secp256k1 is an --expert option and not supported by other *PGP
implementations. We should actually hide this thing even more and not
even display it with --expert. Thus do no expect an immediate 2.5.9
release to fix this issue.

secp256k1 failure:
https://lists.gnupg.org/pipermail/gnupg-users/2025-June/067731.html

Concluded after talking with Carl that there is no need to backport this any more. Therefore retagging this for gpd5x

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):