Things for the Okular PDF Tool.
Details
Mon, Aug 4
Looks good to me on gpg4win-5.0.0-beta357 @ win10
Thu, Jul 31
Tue, Jul 29
Mon, Jul 28
We have now improved error messages, and this, combined with what could be considered a setup issue, I think we can consider this done for now.
Thu, Jul 17
Thu, Jul 10
Likely connected to T7705: Okular: Error on signature if the original file is overwritten
I can confirm this.
Tue, Jul 8
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.
Mon, Jul 7
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.)
Jun 30 2025
Jun 26 2025
Jun 25 2025
On gpg4win-5.0.0-beta330 everything works fine again (both smime and openpgp regardless of expiration).
Jun 24 2025
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
Jun 23 2025
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
@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.
Jun 16 2025
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.
May 27 2025
May 22 2025
May 21 2025
That screenshot is for kleopatra crashing, not related to okular.
May 16 2025
May 14 2025
We have updated patches for long in the gpg4win repo and thus I close this bug.
Mar 26 2025
Mar 24 2025
Mar 12 2025
We investigated this a bit and it only happens when trying to sign with a non VSD key when gnupg is in VSD mode
Something went wrong during signing - the question is what.