For our Okular, we should not use the standard file names (okularrc, …) as this would conflict with a regular Okular installation.

Looks good to me on gpg4win-5.0.0-beta413 @ win11.

I believe this bug was fixed by T7829. Please confirm with new gpgwin-5.0.0-beta.

Looks good to me on gpg4win-5.0.0-beta395 @ win11 (gpg 2.5.13).

Fixed in master: rGae431b04370f: w32:common: Take care of possible race on startup under Windows.

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.

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:

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.

Current logs for a forever hang:

still reproducible on gpg4win-5.0.0-beta369 @ win10

Looks good to me on gpg4win-5.0.0-beta357 @ win10

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.

Likely connected to T7705: Okular: Error on signature if the original file is overwritten

I can confirm this.

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.

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

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

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