Sorry, I can't replicate this

From 1.14.0 on these functions will return a Not Implemented error and the documentation has been removed.

Its a year since I worked on the mentioned wait code change (wk/new-wait branch) and I more or less forgot about it. it will to risky to release that as 1.14 so this change and the fix to this bug needs to be postponed to 1.15. Sorry.

I have also relaxed the test in gpgme for that GnuPG version.

Great! That fixes it. Many thanks!

See T4897 for a patch to gnupg.

It is a pecularity of the test case. A new release is long overdue anyway, so please have a few days patience for a new release with a foxed test case.

Yes, I forgot to include the full build log, I'm attaching it here. I've seen this in OpenSUSE Tumbleweed; the compiler is gcc10; and I can see this on any architecture. The test fails when building against gpg-2.2.21 but not with previous versions.

Pretty please write a useful bug report; we need information on versions, OSes, compilers, any special environment, and all the steps you did to get the build failure. The configure run already prints a lot of useful information; you may want to extract them or provide a complete build log.

Fixed in rM1b840a151ad7: python: Fix how to generate documentation..

I don't think this fix has made it into a release yet. Could we get a released version of gpgme that contains this fix?

Yes, it will fix the problem on x32, I suppose.
If it's difficult for dpkg, for some reason for now, workaround for gpgme packaging is disabling pie hardening for x32 until pie will be its compiler default.
For gpgme, it is only test binaries which matter (pie or not), so, the impact (for x32) is minimum.

on #debian-dpkg on IRC, Guillem Jover suggested that we might want to fix dpkg specfiles to use +self_spec: instead of *self_spec:.

Some information of Qt5 about -fpic:

• https://lists.qt-project.org/pipermail/development/2015-May/021557.html
• https://bugzilla.redhat.com/show_bug.cgi?id=1700435

Debian's GCC build for PIE default: https://salsa.debian.org/toolchain-team/gcc/-/blob/master/debian/rules.defs#L1400

Here is my understanding. My point is it's not problem of gpgme. To fix it correctly, I think that dpkg should be fixed and it would be needed to fix Qt too.

I'm still not understanding what specifically should be fixed here. Sorry to be dense about it, but the range of options and configuration details that are different are pretty puzzling.

Just added a comment to T4826 how to move forward, if this is still interesting for parties. Right now (from my point of view) a pubkey with an expiration date beyond 2106 is not a sensible key configuration, so the use to motivate a chance in this area would need to be argumented better.

Thanks for the patch, applied!
You are correct the NEWS file states that this was added in 1.9.0

I have opened T4939 to add the keylist mode with keygrip.

To end the failures I have modified the test, that needed to be done anyway since different versions of GnuPG behave differently.

Any progress on this one?

On further thought, it's possible that something closer to what
Bernhard wants (and incidentally more along the lines of what I was
thinking of in some of our discussions just after the initial port)
might be achievable with Cython.

FWIW, GPGME is basically C90 and we only recently started to use C99 variadic macros - they are a cpp feature, though.

CFFI has no real means of generating the needed bindings on the fly
like SWIG does, except via its ABI methods, but those are inferior to
what SWIG does. It also can't handle all the ifdefs (or really any of
the ifdefs) in gpgme.h.

In T4883#133467, @werner wrote:

That option does the same as --disable-dirmngr which in trun has the same effect as disable-crl-checks

@werner wrote:

Sample how GpgOL handles this: https://dev.gnupg.org/source/gpgol/browse/master/src/keycache.cpp;6f5f48c3d60e0af52f1a9f0e51f60ee653eeeb31$269

I think what you're saying that there is *no way* to use GPGME in offline mode to validate x.509 certificates, and this is by design. Am I understanding that right?

After disabling the CRL check again in gpgsm.conf

I see no difference between the last two example stanzas that show you running ../run-verify. Are they supposed to have different output?

That option does the same as --disable-dirmngr which in trun has the same effect as disable-crl-checks; see gnupg/sm/server.c#option_handler. If you want to check the validity of the cert you check the TRUST status lines. This is what gpgme does for you. An example is gpgme.tests/gpgsm/t-verify. You can run the tests also manually, I do this as follows:

I think what you're saying that there is *no way* to use GPGME in offline mode to validate x.509 certificates, and this is by design. Am I understanding that right?

I can see no bug here. See my comment over at T4881.

In T4861#132936, @dkg wrote:

0005 and 0006 from the debian distribution of gpgme.

Thanks for the report. Indeed I closed this as a duplicated. Thanks @dkg for pointing out the patches.

Latest one (gnupg 2.2.19)

(I stripped the report down to its core)

Funny. I looked into the history of that function: @dshaw removed the option --list-trust-path from gnupg 1.x in December 2002. He commented

Changing back to wontfix given the wontfix resolution of T4826

I would like to understand why this changed. T4061 might be relevant here. This has been fixed after the 2.2.19 release.

Well thanks for reporting it ;-)

It looks like at least for OpenPGP, the layer below GPGME is also broken for expiration dates in this time window (see T4826)

I don't mind a workaround that avoids an ABI/API fix as long as it defers actual failures until 2038.

I'm reopening this because i think users of these 32-bit platforms are going to run into issues before 2038 happens. Certs could appear expired before they are actually expired, for example, because of the wraparound time.

thanks for looking at this, @aheinecke ! if you or @werner know of any internal side effects where this does matter, it would be great to add a test that documents them.

Merged into master. Thanks!

Thanks! I would merge your commits but I'll like to talk to werner tomorrow about the always adding "--with-keygrip" I also think its useful but it might have expensive internal side effects that I am not aware of.

branch dkg/fix-4821 contains a fix for this, in commit 414938cfedbdb97b83d00e8619dec9502096be22

in particular, c4cf527ea227edb468a84bf9b8ce996807bd6992 and f2aeb2563ba2f55eea7f52041e52062fdc839a64

The dkg/fix-4820 branch now has these two fixes.

For easier reference or searchability, the test error looks like this:

Here's an excerpt of the output which should cover the critical step. Let me know if you need more/all.

Fixed in master and 2.2

Related task: About subkeys is T4028

Prio raised and assigned to werner as he asked for it.

fwiw, ensuring that overflow for either field results in ULONG_MAX (rather than wrapping around) would go a long way toward this problem being something that we can reasonably put off for another 50 years.

Applied and pushed.

The most plausible fix to the Y2K38 problem on 32-bit machines is to simply move to a 64-bit time_t at the same time as any other major system-wide ABI break. However, if that ABI break doesn't also change the size of long to more than 32 bits, GPGME will remain unfixed in spite of any architectural correction.

Very few OpenPGP data signatures have an expiration time either, fwiw. I have never actually seen one in the wild, and no one that i know uses --ask-sig-expire or --default-sig-expire (it shows up in the cupt test suite and the apt test suite, but doesn't appear to be actually used by anything).

CMS signatures do not have a expiration time. Further the meaning of the expiration time of one of the certificates also depends on the validation model (shell or chain); thus a one-to-one relationship between these times is not possible.

We will run into all kind of problems after 2038 on 32 bit boxes. 2106 is nothing to care about.

it is just that we won't fix that for gpg 1.4.

@werner, are you saying that gpgme is not fully supported for use with gpg 1.4?

That seems to be gpg 1.4 which we do not fully support.

Sure: https://gitlab.com/sequoia-pgp/openpgp-interoperability-test-suite/blob/master/src/gnupg.rs#L70

@justus can you provide an example of the gpgme code you're using that generates this weirdness?