Urgs

I pushed the longlong patch: rCb61a7661d017: mpi: Provide the function prototype of __udiv_qrnnd.

The card returned these 32 bytes:

1883ba0d1cacda6f357ad9caa062ebd7b3a07291a7788565caf38973bf414286

agent_card_pkdecrypt however returned 33 bytes:

411883ba0d1cacda6f357ad9caa062ebd7b3a07291a7788565caf38973bf414286

Thus the indicator byte is 0x41. The specs (librepgp, rfc4880bis) say:

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.

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

IIUC, it's actually binutils version dependency (instead of GCC 15), perhaps.

I tested Ubuntu's version of GCC-15 (powerpc64le cross-compiler) and did not see this build failure:

In T7721#203182, @gniibe wrote:

For PowerISA 3.00 Instructions issue, following patch may help:

diff --git a/configure.ac b/configure.ac
index 6cc1e189..70d632af 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2448,10 +2448,11 @@ AC_CACHE_CHECK([whether GCC inline assembler supports PowerISA 3.00 instructions
         else
           gcry_cv_gcc_inline_asm_ppc_arch_3_00=no
           AC_LINK_IFELSE([AC_LANG_PROGRAM(
-          [[__asm__(".text\n\t"
+          [[__asm__(".machine        \"any\"\n"
+                    ".text\n\t"
                     ".globl testfn;\n"
                     "testfn:\n"
-                    "stxvb16x %r1,%v12,%v30;\n"
+                    "stxvb16x 47,0,9;\n"
                   );
             void testfn(void);
             ]], [ testfn(); ])],

I figured out that .machine "any" is needed with GCC 15.

I figured out that .machine "any" is needed with GCC 15.

For Alpha (hppa, and sparc), IIUC, following patch may help:

For PowerISA 3.00 Instructions issue, following patch may help:

In short: A message was saved as an encrypted draft and then the user edited that draft, disabled encryption and then the message was sent out only encrypted to the draft key.

We won't implement that any time soon given that gpgol2 will be an easier plaform to get it right.

Thanks. Will go into 2.4.9 to be released soon.

Here is a patch.

diff --git a/agent/divert-scd.c b/agent/divert-scd.c
index 1e5de4671..bb42dd3b4 100644
--- a/agent/divert-scd.c
+++ b/agent/divert-scd.c
@@ -517,6 +517,9 @@ agent_card_ecc_kem (ctrl_t ctrl, const unsigned char *ecc_ct,

Fixed with new GPGRT_PROCESS_STDIO_NUL flag.

The powerpc64le issue (undefined reference to `gcry_poly1305_p10le_4blocks') also applies to GIT master.

The issue remains with gpg 2.5.9 from Gpg4win-5.0.0-beta345.
Here a gpg-agent log for the failed decryption:

Pushed the changes:

• Inheriting HANDLEs has been not working accurately
  • Before the fix, all HANDLEs were inherited
  • Only specified HANDLEs are inherited by: rE0b01950237ab: w32:spawn: Fix inheriting HANDLEs.
• HANDLEs by w32_open_null were leaked
  • fixed by: rEf28bf71b86ba: w32:spawn: Fix resource leaks for HANDLEs by w32_open_null.

T7723 fix by rE311fb769d1dd: w32:spawn: New flag GPGRT_PROCESS_STDIO_NUL.

Before implementing this feature, it's better to fix T7723: gpgrt:w32: Fix for inheriting stdin/stdout/stderr with "NUL", and do some clean up.

If we will fix gpgconf using GPGRT_PROCESS_STDIO_NUL, we will need to fix gpg-connect-agent to see if it's NUL or not.

In T7721#202963, @werner wrote:

Sure that this is about 1.11.0 ? We released 1.11.1 with at least one fix for gcc regression (T7166). In master we had some more fixes for gcc 15 bugs (or what ever you will call such regression in a compiler)

Sure that this is about 1.11.0 ? We released 1.11.1 with at least one fix for gcc regression (T7166). In master we had some more fixes for gcc 15 bugs (or what ever you will call such regression in a compiler)

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?