- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Today
looks good to me on gpg4win-5.0.0-beta167@win10
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].
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].
Yesterday
To avoid further noise on this ticket, i've done as requested and posted to gnupg-devel : (https://lists.gnupg.org/pipermail/gnupg-devel/2025-May/035875.html
engl. Menu Entry: Save Secret Role Key
Tooltip: Save this secret key to share with other team members.
Discussion and background for naming things and german translation
For the icon:
We decided to
@TobiasFella: please ping on screenshot in MR
Vorschlag Text:
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 ;-)
Add news
Looks good. Please also add the new flags to the NEWS file (similar to what Werner wrote in https://dev.gnupg.org/rMcd79fc39736fda6ce38f1f79700cf658c47372f9).
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