In T6869#200695, @timegrid wrote:

so the non working automatic match of data.sig -> data is another bug?

You cannot trust any signatures made with a compromised key because the signature creation date can easily be forged.

Then why don't we add at least the red background (and maybe an X) instead of the warning sign symbol and no color?

Backported for VSD 3.3.x

so the non working automatic match of data.sig -> data is another bug?

You cannot trust any signatures made with a compromised key because the signature creation date can easily be forged.

In T6869#200687, @ikloecker wrote:

Most of the texts (most are proper sentences) lack a full stop. It's unclear whether this is a bug in the German translation or also in the original texts. This should be fixed.

In T6869#200689, @timegrid wrote:

It's weird that in the "multiple / mixed / split" case the full paths of the files is used even though all files seem to be in the same folder. This isn't really that important.

This is always the case, when the sig file is selected for verification (compared to the verified file itself). Makes probably sense, as the file to be verified needs to be selected explicitly and could be in a different path.

In T6869#200688, @ebo wrote:

One thing: The message for the valid signature from a revoked key looks less worrisome from the user perspective as an invalid signature. Is this intended?
One does not see here if the signature was made before or after the revocation. In the latter case the signature can not be trusted for sure. In the first case it might be ok.

Could we maybe add the time of the expiry or revocation in the message?

In T6869#200682, @timegrid wrote:

• the Show Audit Log link will open the log only on the second click

It's weird that in the "multiple / mixed / split" case the full paths of the files is used even though all files seem to be in the same folder. This isn't really that important.

One thing: The message for the valid signature from a revoked key looks less worrisome from the user perspective as an invalid signature. Is this intended?
One does not see here if the signature was made before or after the revocation. In the latter case the signature can not be trusted for sure. In the first case it might be ok.

Most of the texts (most are proper sentences) lack a full stop. It's unclear whether this is a bug in the German translation or also in the original texts. This should be fixed.

tests with vsd still needs to be done

the changes themself look good to me on gpg4win-5.0.0-beta167@win10

Lucas Mülling commented yesterday on gnupg-devel:

yes please!

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].

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].

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 Team Key
Tooltip: Save this secret key to share with other team members.

Discussion and background for naming things and german translation

For the icon:

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

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.

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 ;-)

merged

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'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.).