The changes have only been implemented for the upcoming Qt 6 based Kleopatra, i.e. Gpg4win 5. I have updated the project tags accordingly.

After completion of T7553, the result for one file looks like this:

tested on gpg4win-4.4.1-beta59@win10

For illustration:

looks good to me on gpg4win-4.4.1-beta59@win10

looks good to me on gpg4win-4.4.1-beta59@win10

looks good to me on gpg4win-4.4.1-beta59@win10

The problem here is that the version number in kleopatra is still 4.0.0-something, which is then compared to 4.4.0.

also fine on vsd-3.3.2.0@win10

looks good to me on gpg4win-4.4.1-beta59@win10

looks good to me on gpg4win-4.4.1-beta59@win10

looks good to me on gpg4win-4.4.1-beta59@win10

looks good to me on gpg4win-4.4.1-beta59@win10

Checked with Gpg4win-4.4.1-beta59, too, which contains gpgme 1.24.3. Works!

Hi, Please review the change and feedback.

Please review the changes and feedback

Please review the patch and feedback.

Please review the changes and feedback.

In T7627#200387, @werner wrote:

We won't apply any fixes to the cpp, QT, or Python language bindings in the 1.24 branch. The Qt branch has been factored out to the gpgmeqt project on request from the KDE folks. And yes, we should add projects (tags) for gpgmepp and gpgmeqt.

Spent some time discovering and unfortunately it's Windows's bug in loopback interface.
I wrote a test demo (blocking mode) to exchange data and watched their packets, found that network stack would drop packets when congestion control algorithm is set to BBR2. It seems the second data exchange was broken.

Problem noted in T7166

Noet that one file is missing in the released tarball; when building for RISC-V please see T7647#201164

Patch applied.

Looking the FIPS 204 document, using the following functions (API) is good:

I can confirm this. Here is the build error:

make[2]: Entering directory '/home/collinfunk/libgcrypt-1.11.1/cipher'
`echo /bin/bash ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I..  -I../src -I../src -I../mpi -I../mpi  -I/home/collinfunk/tmp/include -g -O2 -fvisibility=hidden -fno-delete-null-pointer-checks -Wall -O2 -march=rv64imafdcv -mstrict-align -c rijndael-vp-riscv.c | sed -e 's/-fsanitize[=,\-][=,a-z,A-Z,0-9,\,,\-]*//g' -e 's/-fprofile[=,\-][=,a-z,A-Z,0-9,\,,\-]*//g' -e 's/-fcoverage[=,\-][=,a-z,A-Z,0-9,\,,\-]*//g' `
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I../mpi -I../mpi -I/home/collinfunk/tmp/include -g -O2 -fvisibility=hidden -fno-delete-null-pointer-checks -Wall -O2 -march=rv64imafdcv -mstrict-align -c rijndael-vp-riscv.c  -fPIC -DPIC -o .libs/rijndael-vp-riscv.o
rijndael-vp-riscv.c:58:10: fatal error: simd-common-riscv.h: No such file or directory
   58 | #include "simd-common-riscv.h"
      |          ^~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [Makefile:1730: rijndael-vp-riscv.lo] Error 1

Patch here: https://lists.gnupg.org/pipermail/gcrypt-devel/2025-May/005854.html

In T5993#201111, @werner wrote:

For example Poppler uses GnuPG comment packets to lower its own attack surface by leaving all OpenPGP handling to gpg. The patch (or at least the version we noticed in Fedora and Debian) entirely breaks this use.

(The commits had a wrong bug it in their message)