Fixed by jukvilli’s patch.
__outer

That works, thanks. So does that become part of the next release?
__outer

Both are affected. I updated to reflect that I tested the newer version

Thanks for the reports. IIRC, we had similar reports in the past either here or on a ML.

• For build problems on Raspberry PI see T5251 for a patch
• If you run into "selftest" error see T5254 for a patch (which should be applied in any case)

FWIW, after the release I had some time and after some trouble with my Pi4B I ran into the same problem.

So is this about 1.8.7 or 1.9.0 (as shown in the Version field)?

In fact, Thunderbird does not use gpgme-json, but loads the gpgme shared library at runtime. The interesting thing is that Thunderbird works fine if gpgOSX is used.

Yes, clang + LTO is broken. Maybe there is issue in clang bug tracker for this already?

Maybe this patch helps:

Similar to T5252, likely requiring the concept of some kind of "fixed reference date".

Looking at the backlog of pinentry-related issues, I don’t think that would warrant delaying further the release of pinentry-1.1.1, especially given that the last release was 3 years ago already. Remaining issues (most of them being stalled anyway) or feature requests can be postponed for a future pinentry-1.2.0.

Confirmed working after applying your patch!

The fix will be part of the upcoming pinentry-1.1.1.

Thanks for you report.

@gniibe I assume this issue has been fixed by the same fix as for T4585 and can be closed as well. Feel free to re-open if I am wrong.

Reading the bugzilla report it seems that TB is loading gpgme at runtime. In particular the hints on using externally build stuff (Homebrew) is worrying. Someone(tm) needs to check how gpgme is used by TB and that it is properly initialized. GPGME is actually not designed to be loaded at runtime but should be used as standard shared object or static library.

Thanks for the reply. Not sure about GPGME/gpgme-json. Anyway, it still ends up in gpgme code, isn't it?
I used to modify gpgme sources to receive more information about the issue.
Looks like the next step would be to modify gpg-conf and see what's going on there, or leave it to the Thunderbird developers.

Dependency hell - ask your favorite distribution

Sure that TB uses GPGME - they claimed they won't use it due to license incompatibility (LGPL). I assumed they use gpgme-json via naticve messaging. Regarding the error - I have no idea.

Can you point me to a more elaborate list of the general concerns? (Central directories offer some sort of stable history, namespace and API service towards identifying modules, just like the venerable https://www.ctan.org/ . The solutions built on such services, like programming environment specific "package" and dependency managers that download and install thousands of packages automatically (like yarn) may be debatable, but I am not aware of much general concern against the services itself.)

Thanks for the feedback

Ok, I found the message and tried some opening and clicking around w/o any crashes. But back then I also couldn't reproduce it. Please close the issue. I'll ask for reopening if I ever come across it once more. Thanks for your good work!

We plan this for 1.10 but it may also go into one of the next 1.9.x releases

Docs done.

Typo, sorry. I have no access to pypi and won't apply for an account due to general concerns about those platforms. Thus I can't change that page. Let me assign you this issue ;-)

@werner, that is a missunderstanding:

For a bug which requires more tests (like this one with GnuPG and pinentry), I had a practice to put "Testing" tag.

Any news about this bug? It has been in “Testing” for quite a while now. For what it’s worth, handling of ^C seems to work here as I would expect, so I am inclined to close here and let pinentry-1.1.1 go out. @gniibe, as you did the fix, do you have any comment?

No, this is a fork and we consider the use of a PyPy for GPGME a Bad Thing because it does not guarantee a stable ABI and we accept bugs files against this version.

I set it to Normal priority. It would be good to find out what exactly is the problem with this key so that we can fix this in kleopatra and handle it.

The about dialog where it tells unknown windows version means it's Gpg4win-3.1.13 (the only version affected by T5056 )

I may attempt an update here, who has the pypi maintenance account?
(If we don't have it, we need to ask Justin or create a ticket with the PSF.)