Things for the Okular PDF Tool.
Details
Mon, Oct 13
Thu, Oct 2
I implemented that in the old 2.2 branch for easier testing.
Please let us not clutter the code with OS specific things. We could use a gnupg_remove_ext or gnupg_remove_maybe_wait with a wait parameter which maps to a plain gnupg_remove for Unix. The GPGRT_PROCESS_DETACHED, in the asshelp is also the only specific thing which can be move to a file global macro.
I think that modifying gnupg_remove is a bit risky because it's used in many places.
I'd rather introduce new function for Windows; gnupg_w32_delete_file for this particular purpose.
Factoring out wait_when_sharing_violation function from gnupg_rename_file.
Wed, Oct 1
The gnupg_remove should retry if it has a sharing violation. Similar to what we do in gnupg_rename_file. I just figured that we do a remove in the latter function too w/o handling a sharing violation.
Here is a possible fix:
Wed, Sep 24
I can't find any causes of slowness in keyboxd initialization. I think that there is a situation where it simply takes time on Windows.
Tue, Sep 23
Mon, Sep 22
Current logs for a forever hang:
still reproducible on gpg4win-5.0.0-beta369 @ win10
Aug 13 2025
Aug 8 2025
Aug 4 2025
Looks good to me on gpg4win-5.0.0-beta357 @ win10
Jul 31 2025
Jul 29 2025
Jul 28 2025
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.
Jul 17 2025
Jul 10 2025
Likely connected to T7705: Okular: Error on signature if the original file is overwritten
I can confirm this.
Jul 8 2025
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.
Jul 7 2025
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.