In T4836#132493, @aheinecke wrote:

Thank you for the detailed report.

We recently had a similar problem with S/MIME Mails. T4543 I think that we can apply the same fix we did for S/MIME also for OpenPGP. So I give this high priority as I think that this can be easily fixed and is a big problem in mixed environments.

In T7656#201519, @TobiasFella wrote:

Do I understand correctly that this bug is then automatically done/fixed?

I do not think that this is the only place where such an issue occurs. Maybe we should make the documentation clearer about context key reuse. But the context is specifically designed to cache information about a key, so as to avoid memory overhead. I learned early on that its best for each new operation to use a new context. A context is basically an instance of gpg or gpgsm. So you start one process, ask it for a keylist, keep the process running, start another process, modify the key database, and then ask the first process again about his worldview. Either the first process is a bit confused because it has read data and then that data changed (what happens here) or it has no idea about the change since it was efficient and only read the database once. But here in this example you should be able to reproduce this also by making any other modifications to the key, adding other subkeys, userids etc. That GPGME even notices the secret key is more of a side effect of how the programming works because the GPGME gpg process will ask the gpg-agent (so a third process).

Note: The Kleopatra in upcoming versions of Gpg4win 5 will have AboutData::version set to gpg4win-5.0.0 (or gpg4win-5.0.0-beta190 for beta versions). See T7666: Kleopatra: Rework versioning.

Thanks, that was the only issue building there.

Note: The Kleopatra in upcoming versions of Gpg4win 5 will have AboutData::version set to gpg4win-5.0.0 (or gpg4win-5.0.0-beta190 for beta versions). See T7666: Kleopatra: Rework versioning.

This should compare the gpg4win version number:

I updated the github issue. The suggested change seems to have had no effect.

Thank you @alexk

I made a comment on github.

Please re-open if you find other Cygwin related build problems.

You know that Cygwin is not supported but if that is the only place it should not arm to fix it.

Thanks for the quick fix. I feel a bit silly for not notcing that macro myself...

Fixed in all branches but there is no potential for exploiting. See also gnupg-devel@ ML.

This should do the trick (master) but have not yet tested it:

Fixed. Thanks for the report!

Thank you.

Maybe related:

In T7658#201260, @TobiasFella wrote:

That screenshot is for kleopatra crashing, not related to okular.

That screenshot is for kleopatra crashing, not related to okular.

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

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

Patch applied.

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

Also pushed to 1.11

Using the primary key for ssh was not intended and thus not tested. I have not yet found the time too look closer at your report. Just one remark:

Thank you again for the reactivity! Applied, everything seems to work just fine.

For prompting, I pushed a fix in rG45a11327f3bd: agent: Support the use case of composite PQC for prompting.
Thank you for testing.

Thanks! With that patch applied, decryption works fine.

Thank you for the concrete test case, it helps me.

looks good to me on gpg4win-5.0.0-beta190@win10

I think we have another report on this in the tracker. The problem is indeed the ugly Windows time functions to print a string. Let me only remind that until a few years, Windows had the opinion that Germany uses the Westeuropäische Zeit like Portugal or the UK.

That is quite possible because we do not have a test system for RISC-V and the make release tarbegt is not abale to verify this.

In T7620#200845, @Saturneric wrote:

I think it would be much better if GnuPG automatically performed a key listing immediately after key generation when a smartcard is involved. This would allow GnuPG to detect the presence of the subkey on the card right away, rather than leaving it marked as a stub until the user manually lists keys.

I see that you generated the secret encryption subkey with backup. This means that the secret subkey is generated on your computer, then copied to the card, and then deleted from your computer. The deletion is the reason why the subkey is marked as stub. Only after listing the keys on the card gpg notices that the secret key is actually on the card.

my win10 vm was also installed with german language

Note that old screenshot was made with a version using a gpg from the 2.2 branch.
And on a Windows VM which was (I'm quite sure) installed in German from the start.
In case it matters…

btw, my clue was that in that last --check-sigs, if i used --debug-all i got this:

This affects certification-only primary keys when doing web-of-trust calculations.

works for me, thanks

Backported for VSD 3.3.x

yes please!