Add gpd5x tag to ensure testing with Gpg4win.

Fixed with new GPGRT_PROCESS_STDIO_NUL flag.

It's intentional that with Gpg4win migration from %LOCALAPPDATA% does not work because %LOCALAPPDATA% is used by VSD (and GPD) but not by any old Gpg4win.

As timegrid has not experienced the older versions himself, he misunderstood this. Ingo's description is correct.
(%LOCALAPPDATA% was the location of kleopatragroupsrc before VSD 3.3.0.)

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)

a: expired certificate
Dialog text:
The signature is invalid: The signing certificate has expired.

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

After further discussion, I propose the following. All tool tips and the last dialog text were changed:

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.