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

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.

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.

In T7658#201260, @TobiasFella wrote:

That screenshot is for kleopatra crashing, not related to okular.

That screenshot is for kleopatra crashing, not related to okular.

We have updated patches for long in the gpg4win repo and thus I close this bug.

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.

This is still an issue. Since the double click opens a registry entry the working directory of Okular is Windows. Since it is the working directory of the explorer so that is unusable, but it should still be able to somehow take the location from the actually opened file and use that for a save file suggestion.

This works for me

should this go into the upcomming VSD release?

Existing file. I downloaded a pdf into the local Download folder of my Windows-VM and worked with that.

Is the document loaded from an existing file on disk or directly as a url from a remote server? http(s) or windows share ?

On VS-Desktop-3.1.90.287-Beta I get a suggestion of c:\Windows for saving the signed document, not the users directory any more.
So its gotten worse instead of better...

I want to have this for the next release since I want to use that mechanism for the promised "Tender version of Kleopatra". This will mean that we replace the "VERSION" file with a QSettings ini file where we can easily add more meta information as we like.

From my practical expexperience, @ebo's suggestion will work best for me. The other thing I have seen is to not use -signed but to append the initials of the signers.

I know Microsoft is probably not the best example, but copying an already copied file with the Windows Explorer you get "Copy of Copy of Copy of originalname.txt". Moreover, I think foo_signed_signed_signed.pdf makes it pretty clear that this is a PDF that has been signed multiple times. I would leave it as-is. People who don't like the name can easily change it.

How about adding "-2" to a document where before _signed already was in the name, i.e. foo_signed.pdf -> foo_signed-2.pdf and so on: foo_signed-3.pdf, ...

Just for reference:
Make it signature pretty: https://dev.gnupg.org/T6732
Default path: https://dev.gnupg.org/T6731
signed_signed: https://dev.gnupg.org/T6730

Unfortunately, "make it not ugly" is a bit hard to work with. I'm open for ideas.

I'm going to assign this to @aheinecke - but @ebo might also have opinion on how it would be nice.

As this issue was originally just about the "versioned file" and where to place _signed, I think we should keep this closed. Will create new issues based on the notes here.

I'm told that this is also what acrobat does, which is one of the reasons for the current approach.