@werner: Is this resolved?

I also tested to add the qual flag to the root cert in the global trusted.txt, as using qualified.txt is considered legacy, but still the same behavior

The first time Okular was included is gpg4win-4.2.0:

See here for how it should look like:

• https://invent.kde.org/graphics/okular/-/merge_requests/1120
• https://invent.kde.org/graphics/okular/-/merge_requests/1121

I see. I added the root cert to C:\ProgramData\GNU\etc\gnupg\qualified.txt and the usage of the signing certs does include a qualified signature in Kleopatra now. Still I don't see any highlight/filter in Okular:

None of these certificates are for qualified signatures.

Try compare with a gpg4win 3.latest.

On gpg4win-5.0.0 @ win11 I created a bunch of smime certs:

• For each keyusage
  • keyEncipherment, dataEncipherment
  • digitalSignature
  • nonRepudiation
  • digitalSignature, nonRepudiation
• Alice's certs with different names, Bob's certs with same name for each key

Was anything changed? What to test here?

Thanks, looks good to me:

• Saving to c:\windows
  
• Saving with removed signing key
  

A way to trigger some errors could be trying to save to c:\windows or some other place you can't do.
Or while you have the key list open in okular, remove the key underneath everything and then continue.

We now have a filter for qualified signatures if there is any in the list

Fixed upstream with https://invent.kde.org/graphics/okular/-/merge_requests/1301 - not yet in our packaging

That was also fixed in gnupg 2.2.50 and thus vsd 3.3.3

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

How does gpgsm react if you try to sign with the certificate?

Maybe it would be better to just not offer S/MIME certs with distrusted root cert?

Note: It does not seem to be possible to open a pdf from an URL, at least not via CLI okular.exe <URL> (it says Unknown protocol 'https').

I tried to get any error response but found those issues instead:

• T8017: Okular: Hang on signature with smime cert and distrusted root
• T8018: Okular: No error on signature with wrong passphrase

If all processes are killed before okular is opened, i get an error:

gpgsm.log (debug-all, whole process of signing)

Looks good to me on gpg4win-5.0.0-beta479 @ win11. The default path is now the same as the path of the opened file:

Yes, Kleopatra quits again with the beta from yesterday:

Fixed in gpg4win-5.0.0-beta476

Fixed by applying a patch to our version of MinGW. This affected all Qt programs build with Qt 6.10.

Yes, this is obsolete with T7717: Location of qt-application config files. Closing as Wontfix because we use product-specific folders outside of GNUPGHOME.

In T7285#209655, @ebo wrote:

@svuorela Isn't this done already for KF6?

@svuorela Isn't this done already for KF6?

Is this ticket obsolete with T7717: Location of qt-application config files?

This should better be fixed in the v5 release

With the product-specific standard locations implemented for T7717: Location of qt-application config files it's now longer necessary to customize the application name of Okular. Closing as wontfix.

The new approach has been implemented and backported for VSD 3.4.

New new plan (after discussion on 2025-12-08):

While working on https://dev.gnupg.org/T7962 I realized that https://dev.gnupg.org/T7717#208938 is probably not the best solution for separating the config files of different distributions of Kleopatra, Okular, etc. Changing the application name has many side effects, e.g. it changes the name of the config files, but that's unnecessary because we put the apps' files already in different folders. There are also other side effects that make things complicated (and require many changes in okular). Taking a step back what we need is different folders for VSD, GPD, and Gpg4win (and KDE Okular). And, for Kleopatra, we need different unique service IDs, but let's ignore this for now. That can easily be solved separately. For the different folders it would be sufficient (and maybe even nicer for selective backups) to use something like %(LOCAL)APPDATA%/GnuPG VS-Desktop, etc., as location for all apps' files of VSD/GPD/Gpg4win. Then we wouldn't have to change/patch anything in Okular (or any other Qt apps).

Backported for VSD 3.4

This is now implemented for Gpg4win 5.

For our GnuPG 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