I created a Go test program that runs several Go routines, each of which verifies a byte array loaded from a file in advance. Each go-routine is spawned with a configurable delay in milliseconds. I tested it with 100 iterations, which resulted in at least 50 parallel processes. Each verification process uses its own context, as Crio does. I didn't encounter any errors.

Here is my repository with a README containing more information: https://git.sr.ht/~kulbartsch/gpgmego-verify-load-test

I have not tested this extensively but it seems to me after some fast checks that the pivotal point here is the usage of a brainpool key on a smart card for the decryption.

I have not tested this extensively but it seems to me after some fast checks that the pivotal point here is the usage of a brainpool key on a smart card for the decryption.

Here is an experimental change to support the feature.

I'm testing the following patch with experimental change of libgpg-error.

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

I can confirm this.

We already have an initialization function in gpgrt which is thread-safe at least if used as a DLL. Maybe move the check to there.

In libgpg-error, we have: rE65114f24e13f: w32: More changes to the extended length path handling.

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

commands with -v

Please always add -v t commands like "gpg --decrypt test.txt.gpg". To decide whether this is smartcard or gpg-agent releated, I need to see a log file form gpg-agent and scdaemon. The latter is more important. I would suggest "debug ipc,app,cardio"

Ok, it was a missing update (although windows claimed to be up-to-date).
After installing 2025-06 [...] KB5060829 the Microsoft Print to PDF feature is available again and printing also works in Kleopatra/Okular.

A second patch fixes the problem with the button in the smart card view.

I have added a patch to disable recoloring of the status icons in Gpg4win. This ensures that the status icons in the selected rows don't get all-white.

Upstream bug report for invisible status icons: https://bugs.kde.org/show_bug.cgi?id=506434 (Icon coloring is inherently incompatible with colored Breeze status icons)

It's also the same error in Okular, when a pdf is printed.

Same on gpg4win-4.4.1 @ win11 (here a bit more debugview context)

3	3.503991	8584	kleopatra.exe	org.kde.pim.kleopatra: Paperkey export finished:  0 status:  QProcess::NormalExit
4	3.691599	8584	kleopatra.exe	QPrintDialog: Cannot be used on non-native printers
5	3.691981	8584	kleopatra.exe	QPrintDialog: Cannot be used on non-native printers
6	3.692752	8584	kleopatra.exe	org.kde.pim.kleopatra: Printing aborted.

Works fine here.

version

C:\Users\g10\Desktop\tmp\scdecrypt>gpg --version
gpg (GnuPG) 2.5.8
libgcrypt 1.11.1
Copyright (C) 2025 g10 Code GmbH
License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg --version?
gpg -K?

You're right, it also errors on gpg directly:

I can't reproduce. Please check whether this works if you use gpg directly; it's a bit unlikely that this is kleopatra-specific, since kleopatra doesn't really care whether the key is on a smartcard or not.

In T7639#202620, @timegrid wrote:

If this should also work in gpg4win-5.0.0-beta336 @ win10 (beta compliance mode), it does not:

If this should also work in gpg4win-5.0.0-beta336 @ win10 (beta compliance mode), it does not:

This only happens, if the smartcard key

• is the only key in the keyring or
• was used for sign/encrypt earlier and thus saved as selection default.

Thanks, confirmed then, moving to Done.

In T7232#202509, @timegrid wrote:

With above configuration it seems to work on gpg4win-5.0.0-beta336 @ win10.
Any way to verify in kleopatra, that the setting was applied?

Looks good to me on gpg4win-5.0.0-beta336 @ win10.

With above configuration it seems to work on gpg4win-5.0.0-beta336 @ win10.
Any way to verify in kleopatra, that the setting was applied?

Looks good to me on gpg4win-5.0.0-beta336 @ win10.

Looks good to me on gpg4win-5.0.0-beta336 @ win10.

Looks good to me on gpg4win-5.0.0-beta336 @ win10.

Happens also in the group config (warning icon):

Related? In smartcards view:

This also happens on Linux. And even with the Fusion style.

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

Fixed in 2.5.8.

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:

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.

Done by: rM8caa7cc517eb: Use sysconf as a fallback mechanism in the initialization.

OK. I'll add a code for setting the fallback value in _gpgme_io_subsystem_init and use it from get_max_fds.

iirc we introduced sysconf (_SC_OPEN_MAX) for non-linux platforms and that fixed real world problems. What about getting this value at module initialization time and keep on using it as a fallback?

For issues of get_max_fds, I created a sub task, although it seems not the direct cause of this particular problem.

I test following test program (gcc -o t-gmf t-gmf.c) on Debian machine of S390x.

There should be a workaround by using

In the log, we can observe duplicated lines generated by
https://dev.gnupg.org/source/gpgme/browse/master/src/posix-io.c$545
Example is like:

2025-05-19 20:16:35 gpgme[21970.55d7]   _gpgme_io_spawn: check: fd[0] = 0x1c -> 0x1
2025-05-19 20:16:35 gpgme[21970.55d7]   _gpgme_io_spawn: check: fd[0] = 0x1c -> 0x1

Done in 1.11.1.

Done in 1.11.1.

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.