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 remeber that untile a few years, Windows had the opinion that Germany is the the Westeuropäische Zeit, i.e. 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!

The status bar is now updated in case the VERSION file is loaded after the main window was created.

Kleopatra does not show version information in the status bar. It does show whatever is stored in the VERSION file under the key statusline in the group [Kleopatra].

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

In libgcrypt/cipher/ecc-ecdsa.c, we have:

mpi_mulm (s, k_1, sum, ec->n);    /* s = k^(-1)*(hash+(d*r)) mod n */

Hi Werner, I submitted a patch right after this bug report using AC_CHECK_DECLS([_sys_siglist]) [1].

The first call of get_key receives the following key listing from gpg:

2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: sec:-:256:19:C4A24EB0B5F2E025:1746474606:::u:::s
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: cESCA:::D2760001240100000006180489130000::brainp
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: oolP256r1:23::0:<LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: fpr:::::::::DEC0948C398A6E7B50746EC6C4A24EB0B5F2
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: E025:<LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: grp:::::::::06BDACFBDEDBC5783A75AE5E7251FA3369C4
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: 0FF4:<LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: uid:-::::1746474606::2222D8E2F373B9BDEE0DEA2A20A
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: 9402214E9F984::Eric <eric@bktus.com>::::::::::0:
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: <LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: ssb:-:256:19:EAFC5EA29B758B22:1746474606::::::a:
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: ::D2760001240100000006180489130000::brainpoolP25
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: 6r1:23:<LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: fpr:::::::::1AD596DDEC9B8CF3C1AC6C41EAFC5EA29B75
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: 8B22:<LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: grp:::::::::52F0797C0B0439BBD718E2534D46656A6C45
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: 6A78:<LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: ssb:-:256:18:A874804DB497B91C:1746474606::::::e:
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: ::#::brainpoolP256r1:23:<LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: fpr:::::::::33B273C7BD46E4EB63DD6874A874804DB497
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: B91C:<LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: grp:::::::::34A1F8D9B2AA0CF07C2E042D70E10F9D4EBE
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: E734:<LF>

Note the line

ssb:-:256:18:A874804DB497B91C:1746474606::::::e:::#::brainpoolP256r1:23:<LF>

where the # marks the subkey as stub.

Right now we have

Interesting, that sounds like a portable method. I am not very familiar with GPG internals, but to me that sounds like quite a bit of work. Unless there is another benefit to doing so, I don't think it is worth it just to print signal names.

Yep, I wrote a small client and server just to verify that it is functional.

I have now identified the exact conditions and a reproducible path for the issue I previously reported. I will also attach the relevant gpgme.log.

I doubt that this is a gpgme problem. With a gpgme log we will be able see the exact commands send to gpg and replicate this on the command line.

Should be fixed.

For gpgme 2 we changed the data types of the time fields to unsigned: rMf2d40473b522e348d96a70c089d2191d0b978098 . Since this change breaks the ABI we use the above change for the 1.24 branch.

And the US administration might even change the definition of a year to, say, 100 months so that potus can rightfully keep his promise that there won't be more election in the foreseeable future ;-)

By the way, "years" is also "incorrect" once in ~4 years because it uses n*365 days. Werner's advice still applies. Enter an ISO date if you want an exact date. Or use a UI tool like Kleopatra.

tested @ikloecker's patch succesful on amdahl.

The following patch for gpgme 1.24 should fix the test.

diff --git a/lang/cpp/src/key.cpp b/lang/cpp/src/key.cpp
index 42046aa..2b14d90 100644
--- a/src/key.cpp
+++ b/src/key.cpp
@@ -633,7 +633,7 @@ time_t Subkey::creationTime() const

I did a local change (on amdahl.d.o) changing _gpgme_subkey.expires to long long (ABI-break) and all tests succeeded.

It looks like the entirety of gpgme timestamping was missed when the 64bit time transition happened in Debian and Ubuntu.

This looks like a problem in gpgme. struct _gpgme_subkey stores the expiration date as long int expires which is a signed 32-bit value on all 32-bit architectures. gpgmepp casts this to time_t, but that doesn't help if the 32-bit value is already negative. The same problem exists with all other timestamps in gpgme (i.e. key creation date, signature expiration date, etc.).

But the function works and returns the peer's credentials?

The main problem here was that this all is not async-safe and thus I once implemented only the standard cases I could test easily.

The logs of gpgme would be helpful, i.e. run your test program with GPGME_DEBUG=8:$(pwd)/gpgme-$(date +"%Y-%m-%d-%H%M%S").log to create a log file with gpgme's logs.

Yes, this is related to T7547. With my last fix for that I overlooked that we use PUBKEY_USAGE_CERT to internally request the primary key but that one is not set because in general USAGE_SIG means the same (except for some case in PGP7 mode).