This is addressed in my blog post; I set the GPG executable used by Git in the configuration so that it uses the one shipped with Gpg4win:

Looks good to me on GnuPG-VS-Desktop-3.3.90.8-Beta-Standard.msi (3.3.3 betaversion) @ win10
(tested with 10 restarts)

Looks good to me on GnuPG-VS-Desktop-3.3.90.8-Beta-Standard.msi (3.3.3 betaversion) @ win10

The problem is likely the gpg which comes with Git on Windows. Depending on where they are in the %PATH% a wrong one will be used. Please run gpgconf -L to check that the correct version of gnupg is used. I have never used git on Window but I would suggest to remove the gnupg binaries which come with Git and adjust the gpg.exe name in the global config.

It's in master (to be 1.12), then, it's backported to 1.11.2, which is confirmed build well.
So, closing.

Thanks for testing.

Hello,
thank you all. I can confirm that 1.11.2 builds successfully on ppc64el with gcc-15 (Debian sid + experimental). Lacking access I have not be able to check alpha. I would suggest closing this report as fixed.
cu Andreas

OK on Linux now with new enough versions (Fedora 42).

Finally came around to check this.
On Fedora with Kleopatra 25.04.03, gpg 2.4.5 and pinentry 1.3.1 the pinentry window ist above the Kleoaptra windows.

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

Pushed the changes in {gniibe/synch-spawn} branch.
It consists of three commits:

• rGb8b8afc5cf6f: build: Require libgpg-error 1.56 or newer.
• rG15b8bc7495db: w32: Synchronous spawning gpg-agent/dirmngr/keyboxd.
• rG6bd6826aa6ff: common:w32: Care about the NUL device for start_new_service.

Ok, thanks. I pushed the powerpc patches to master.

tested with Gpg4win-5.0.0-beta357 (GnuPG 2.5.11):

I can confirm that the crash is fixed by the change.

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.