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.

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.

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!

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?

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 )

It's version 2

Please let us know your gpg4win version.

I am getting the initial exception again:

That would mean I could remember the exact problem. Can you extract the mail name from my logs? I should still have it...

Note: The commit in master (1.9) is rCe0898d0628789414
and in 1.8 it is rC03e6d6597198ee

The commit which fixes this is rC761a1a0d30

This works with the message class changing. We still need to do it for OpenPGP, too.

The code has been reworked to also support the updated schema which also stores the fingerprints and a parsed down mail address. See gnupg/doc/ldap/ . These changes are in master and 2.2.26. Sorry for taking so long to fix that.

Yes, bug is also in 1.8 branch.

I'm also getting this same error with GPG4Win 3.1.14.

Do we need to backport to 1.8?

Thanks. I added the OIDs and the missing curves. To go into 1.9

Okay. Now since configure.ac is already touching CFLAGS, it seemed like a good place to add that additional option here. All this is guarded by a test for GCC, and since clang mimics that behaviour, it works for them as well.

Take care: gpg is also used on platforms with proprietary compilers which don't support -f options. Thus you need to limit this to gcc.

After some more checking: LLVM-11 introduced the same behaviour in that regard, but appearently not a pragma/attribute to override this: https://releases.llvm.org/11.0.0/tools/clang/docs/ReleaseNotes.html

This works now with 0c1bd9076958e584820fadf997ca7d8a248b6888 but needs more testing before this can be relased. It will probably be part of a Gpg4win-4 beta.

I'd suggest to first try the current version to see whether the bug has been solved.

Please try gpg4win 3.1.14 and check whether your problem has gone.

Thus better add a

&& !defined(__clang__)

Sure that the FreeBSD compiler does not define it? I am pretty sure it does.

According to list of attributes in the clang 12 documention, there is no such attribute in clang. However, the clang-11 compiler (as seen in Debian) does not define __GNUC__, so the proposed patch does not affect the status when building with clang.

You may want to check that clang supports this attribute as well.

Build Result:

In T5214#140791, @werner wrote:

For directories this can't be done because not only the server reads the directories but also other deployment tools (e.g. rsync).

I fixed the latter two points. For directories this can't be done because not only the server reads the directories but also other deployment tools (e.g. rsync).

I removed gnupg from the %AppData% directory and restarted Kleopatra, but I am running into the same permissions issue.

please move away %AppData%\gnupg
it usually expands to c:\users\yourusername\AppData\Roaming\gnupg

Screenshots of the issue are attached.

Please report about released versions. If you have problems building from Git, posting to gnupg-devel is the best way forward,.

The patch will be in 2.2.27. Thanks.

Simply add -v or --verbose to the gpg invocation too see infos about the pinentry. --debug-level is not helpful here.
And well, we don't have a way to test stuff on Vista anymore. You should also update to at least Windows 7.

Good catch. This is due to back porting a change from master. However the extra introduced conditional of

if (sig->version >=4)

will always evaluate to true. It is set a bit above and GnuPG does not handle public key packets with version 3 anymore. So this if can actually be removed. Thus no harm.

Please provide detailed information about the build peoblem. An arbitrary paste from a build does not make up a bug report. If you need support building GnuPG you may want to look for a commercial offer or to ask on a mailing list. From what I see I assume you have an incomplete installation of the supporting libraries.

Already have set another, thanks gnibe! See ya!

Please change your passphrase for your card, BTW.

Good. The error recovery worked well.

Thanks for reporting this. You are correct, those HWCAP2_SHA1 and HWCAP2_SHA2 defines are wrong.

Thanks, appreciated.

You are lucky. The report came just in time for the 2.2.26 released. Not mentioned over thre but anyway fixed. See T5153

This is x86_64 (amd64) Fedora Linux version 32 (nothing to do with the x32 sorta-architecture).

Oh well, sshfs.

Just for reference what OS and file system is this? It looks like some x32 Linux.

GnuPG uses the systems locale.