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.

A bit tricky to fix unfortunately, making the window active is not really possible on Windows. See https://doc.qt.io/qt-6/qwidget.html#activateWindow but there seems to be some tricks one can use: https://forum.qt.io/topic/1939/activatewindow-does-not-send-window-to-front/11?_=1750663659477

Done by: rM8caa7cc517eb: Use sysconf as a fallback mechanism in the initialization.

In case of problems with token based cv25519 key, please update to 2.5.8.

OK. I'll add a code for setting the fallback value in _gpgme_io_subsystem_init and use it from get_max_fds.

iirc we introduced sysconf (_SC_OPEN_MAX) for non-linux platforms and that fixed real world problems. What about getting this value at module initialization time and keep on using it as a fallback?

For issues of get_max_fds, I created a sub task, although it seems not the direct cause of this particular problem.

I test following test program (gcc -o t-gmf t-gmf.c) on Debian machine of S390x.

We decided in T7579: Kleopatra: improve menu items to remove this action. Users will instead have to mark certificates they want to update and use the Update Certificates action in the "Certificates" menu.

After several gpg4win-5 betas be can set this task to resolved.

I claim this resolved given several gpg4win-5 betas.

I claim this resolved given that we had several gpg4win-5 betas and no reported problems was related to this.

The actual project we had in mind for this was more or less canceled and thus I re-prioritize this task.

Reminder mostly to self: This is about the KDF parameters. In the light of PQC composite algorithms we may want to also prepare for PQC required stuff.

There should be a workaround by using