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?

The Python doc build system we implemented the last year is a complete mess - I had so much trouble the last time I did a release :-(.

i'm actually running make -j3 check, since make -j3 distcheck has the problems described in T4688.

So i've been able to (intermittently) reproduce the failures that i think @werner was alluding to here, but not under any circumstances where i can get them to happen reliably to understand what's going on.

This pretty much matches my test setup. As the crash is in GPGME it is out of Kleopatra's hand. So I'll try to write a test that repeats such a signing for lots of times. I think this is probably some random race condition.

I don't think I can reproduce it, at least it didn't happen anymore after restarting and continuing the imports. AFAIR it happened after importing the "Master Key", during trying to import the "Release Key" from https://www.chiark.greenend.org.uk/~sgtatham/putty/keys.html
Ah and maybe one more hint: I have several keypairs, so the dialog for choosing the keypair to be used appears in the next step.

Fixed.

yes, python2.7 and python3.7

Using several python versions?

rM7d0a979c07d2 disabled the test for this. @werner says:

Because this is a GPGME bug.

why is this fix not relevant for the 2.2 stable branch? I've had no feedback on this proposed patch.

I closed this as a duplicate of a newer task because I did not find this issue when creating T4561 and there was already work done for T4561.

Okay, so the open task is to build gpgme with MSVC in a way that different libnames are used and that we can distribute them along our standard DLLs? Given the easy we can now ssh into Windows there won't be a need to Wine things.

One issue with this is that Qt Webengine (chrome) cannot be built with mingw. Fixing that would be a major project.

High priority and half a year no action....

Werner: I'm assigning this to you. Because the underlying reason is a missing status from gpg. I think we should add that for 2.3 as any new status line tends to break things.

Hello,
when can we fix it?

without feedback, i have no idea what you want to do here as upstream. I believe this issue has identified a specific failing use case, and it has a patch that fixes the problem. if there's a problem, please let me know what it is. If there's no problem, please consider merging.

I note that "the best" seems like it might be a pretty subjective thing. The standard GnuPG framing asks about the validity of keys for the User ID in question. Perhaps the caller could indicate whether they want to require full validity for each key to make this key selection more strict.

The function would do something like:

• from msg, extract all e-mail addresses from to, cc, bcc fields
• find "the best" keys that match these addresses, storing them in keylist
• copy msg to tmp, remove bcc header from tmp
• wrap armored output of gpg.Context.encrypt(bytes(tmp), recipients=keylist) in the necessary RFC 3156 cladding, copying most headers from msg (maybe stubbing out the subject), producing an email.message.EmailMessage object.

This seems to be closely related to T4257 for which I have a fix under test. The problem is that we pass the fd used by the caller to create the data object to gpgsm and close that very fd. The descriptor passing involves an implicit dup so closing is in theory okay but we should not close an fd which has been set (w/o dup) by the caller.

Release done.

I have a larger change for the wait code in the works. This will go into 1.14.0 but not in 1.13.1

I had to patch strace to follow threads but not forks (P8) and then when built with support for -k I tracked it down: In the inbound handler we close the fd immediately on EOF. However the upper layers don't know about it and a select fails with EBADF. Of course we could ignore the EBADF, figure out the closed fd and restart. The problem is that another thread may have opened a new oobject and that will get the last closed fd assigned - bummer.

Just noticed that due to me failing to properly understand re-entrant locks the run-thread test is broken at least on windows in that it never waits for completion. So running out of filedescriptors is to expect. I'll fix the test.

My observation from running the verify threaded test on windows is that it does behave differently. The EBADF does not occur.

Something(tm) closes an arbitrary file descriptor behind our back. Not easy to track down because strace can not trace only threads - it always wants to trace all children as well - which is a bit too much and leads to other problems.

Log loops with:

I have a hang now when keylisting in Kleo with GPGME_DEBUG=9:

any feedback on this proposed patch?

The solution conflicts the the fix suggested and implemented for T4330.

Fixed similar to the suggestion but NaN and INF are detected earlier.