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

Correction, the _ALL_SOURCE definition only applies if __cplusplus is defined... Strange platform...

I think you are correct.

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.

The report is correct but it does not make sense to fix it. If you want to use a concrete expiration date just enter the IS date at the prompt; use ? at the prompt for a short description.

Fixed:

Thanks for the patch but I think it is better to fix this in yat2m. I created a new tag for bugs related to it.

This is really a minor thing and and it is actually true if you also sign something.

doc/HACKING says it's OK to use variadic arg macros (from C99 features).
If it's OK, this patch can fix the initialization (which silences GCC 15 warnings):

Good morning,
I stumbled upon this when digging through old Debian bug reports against 1.4 and checking whether they still applied to 2.4. This one really still applies.

IIUC, it's GCC 8 which starts the support of __nonstring__ attribute.

POSIX specifies and requires grep -E, but only mentions egrep as old.

Removing egrep from a Unix system will break all kind of stuff. I am not even sure whether old Unices support grep -E.

And, one more update, to fix win32 builds under --disable-npth. This is a roll-up patch that i think covers everything, you can disregard the earlier patches posted here.

Hm, we probably should avoid gpgv linking to npth as well, as that's also a sticking point in debian. This updated patch (also targeting the 2.4 branch) also has gpgv building against libcommon instead of libcommonpth, which appears to remove the dependency for me.

This patch avoids the unnecessary libassuan linkage by creating a set of stub functions to handle the keydb formats while avoiding potential callouts to keyboxd:

Well, I could not reproduce this at any time but tested decryption with long file paths to be sure nothing broke and it worked fine.

There is no well defined pripority for the CRL DPs. The code enumarates the DP and tries one after the other until it founds one. If you use --ignore-http_dp http DPs are skipped and with --ignore-ldap-dp LDAP DPs are ignored.

1.53 has been released this morning.

this marked as fixed in 2.4.7. However afaict only one of the two patches made it to STABLE-BRANCH-2-4, b1857a2836c9a91ef4e359ef7ba949b54c77219d did not.