Yesterday
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 screenshot was made with 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…
Wed, May 7
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].
Tue, May 6
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.
Mon, May 5
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
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?