If Okular is started without background processes already running and a smime signed pdf is opened, it gets unresponsive for ~20s or might hang forever (timeout waiting for Dirmngr):
gpgme log (GPGME_DEBUG=9):
gpgsm log (debug x509,ipc,lookup):
Note: Pdf signature created with vsd 3.3.2
The only time I succeded in reproducing this was when I broke my gnupg setup and got a mix between gpg from one version and gpg-agent from another.
I'd like a bit of ideas here; including if it is still reproducible
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.
But I can still reproduce the signing part: okular displays this "all signing certs are invalid or expired" althought the signing certs in kleopatra are valid:
To reproduce:
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.
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.
@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 ?
Shouldn't be needed because of https://dev.gnupg.org/rMf2d40473b522e348d96a70c089d2191d0b978098 which changed the type of expires to unsigned long int.
Here's the gpgsm debug log (debug x509,ipc,lookup):
Okular showes signed file after ~10s:
Okular hangs forever:
looks like it's clear why:
2025-06-23 13:18:54 gpgsm[7972] Kein aktiver keyboxd - `C:\\Program Files\\GnuPG\\bin\\keyboxd.exe' wird gestartet 2025-06-23 13:18:56 gpgsm[7972] Warte bis der Keyboxd bereit ist ... (8s) 2025-06-23 13:19:18 gpgsm[7972] Warte bis der Keyboxd bereit ist ... (7s) 2025-06-23 13:19:21 gpgsm[7972] Warte bis der Keyboxd bereit ist ... (6s) 2025-06-23 13:19:23 gpgsm[7972] Warte bis der Keyboxd bereit ist ... (5s) 2025-06-23 13:19:26 gpgsm[7972] Warte bis der Keyboxd bereit ist ... (4s) 2025-06-23 13:19:29 gpgsm[7972] Warte bis der Keyboxd bereit ist ... (3s) 2025-06-23 13:19:31 gpgsm[7972] Warte bis der Keyboxd bereit ist ... (2s) 2025-06-23 13:19:34 gpgsm[7972] Warte bis der Keyboxd bereit ist ... (1s) 2025-06-23 13:19:37 gpgsm[7972] can't connect to the keyboxd: IPC "connect" Aufruf fehlgeschlagen 2025-06-23 13:19:37 gpgsm[7972] Fehler beim Öffnen der Schlüsseldatenbank: Keybox-Daemon läuft nicht 2025-06-23 13:19:37 gpgsm[7972] Kann keinen KeyDB Handler bereitstellen 2025-06-23 13:19:37 gpgsm[7972] DBG: chan_0x0000000000000228 -> S ERROR verify.leave 50331649 2025-06-23 13:19:37 gpgsm[7972] DBG: chan_0x0000000000000228 -> ERR 50331649 Allgemeiner Fehler <GPGSM> 2025-06-23 13:20:53 gpgsm[7972] DBG: chan_0x0000000000000228 <- [eof]
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
Another 6 seconds are lost starting gpg-agent.
2025-06-23 13:17:01 gpgsm[3252] Das Zertifikat ist korrekt 2025-06-23 13:17:03 gpgsm[3252] Kein aktiver gpg-agent - `C:\\Program Files\\GnuPG\\bin\\gpg-agent.exe' wird gestartet 2025-06-23 13:17:03 gpgsm[3252] DBG: chan_0x000000000000022c -> S PROGRESS starting_agent ? 0 0 2025-06-23 13:17:05 gpgsm[3252] Warte bis der gpg-agent bereit ist ... (8s) 2025-06-23 13:17:07 gpgsm[3252] DBG: chan_0x0000000000000278 <- OK Pleased to meet you, process 4260
And 9 seconds are lost starting dirmngr.
2025-06-23 13:17:07 gpgsm[1808] Der Herausgeber wird im Cache des Dirmngr gesucht 2025-06-23 13:17:09 gpgsm[1808] Kein aktiver dirmngr - `C:\\Program Files\\GnuPG\\bin\\dirmngr.exe' wird gestartet 2025-06-23 13:17:09 gpgsm[1808] DBG: chan_0x0000000000000228 -> S PROGRESS starting_dirmngr ? 0 0 2025-06-23 13:17:12 gpgsm[1808] Warte bis der Dirmngr bereit ist ... (8s) 2025-06-23 13:17:16 gpgsm[1808] DBG: chan_0x0000000000000280 <- # Home: C:\Users\g10\AppData\Roaming\gnupg 2025-06-23 13:17:16 gpgsm[1808] DBG: chan_0x0000000000000280 <- # Config: C:/Users/g10/AppData/Roaming/gnupg/dirmngr.conf 2025-06-23 13:17:16 gpgsm[1808] DBG: chan_0x0000000000000280 <- OK Dirmngr 2.5.6 at your service, process 5856 2025-06-23 13:17:16 gpgsm[1808] Verbindung zum Dirmngr aufgebaut
That's about 20 seconds total just waiting for the start of three processes. At least, keyboxd and gpg-agent could easily be fired up before by doing a keylisting in the background when Okular is started. Of course, that doesn't help that much if the user double-clicks a signed PDF when no gnupg processes are running. OTOH, we need to be careful not to sink too much time into optimizing something that mostly occurs during testing with loads of different GNUPGHOMEs. For a normal user gpg-agent and keyboxd will usually be running except immediately after rebooting because both daemons keep running until they are explicitly terminated. And we all now how often people reboot nowadays. They reboot only if the system forces them to reboot after an update. In other words, people might notice the delay once every few weeks. And to avoid those delays the correct fix might be autostarting gpg-agent and keyboxd. On Linux, it's no problem to start them on demand because it takes a fraction of a second, but on Windows...
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.
But I do think that rather than figure out how to preload these daemons, maybe we should figure out why they are so slow to start up ?
The problem with the invalid certificates seems to be unrelated. Isn't there already a ticket for Okular for certificates which expire after 2038?
3 non-hang logs, all took ~20s to open the file (with 20s "Keine Rückmeldung" shown in Okular)
Issue about no valid smime certs found on signing split into: https://dev.gnupg.org/T7697
I have built the run-* test programs of gpgme for Windows. run-keylist --cms --secret takes about 23 seconds. 3.7 seconds are gpgme initialization/setup (gpgconf --list-dirs, gpgconf --list-components, gpg --version, gpgsm --version, gpgconf --version). Most time (2 x 6-8 s) is lost starting gpg-agent and dirmngr. (keyboxd is not enabled here.)
Staring at some Process Monitor logs I noticed that dirmngr wastes 3-4 seconds trying to connect to localhost:9050 and localhost:9150 looking for tor. After adding no-use-tor to dirmngr.conf dirmngr starts reasonably fast.