The changes have only been implemented for the upcoming Qt 6 based Kleopatra, i.e. Gpg4win 5. I have updated the project tags accordingly.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Yesterday
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.
Mon, May 19
In T7627#200387, @werner wrote:
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:
Sun, May 18
Sat, May 17
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
Fri, May 16
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)