Was Okish in my last tests. But I did not fix anything compared to 3.1.0

The commit mentioned fixes the problem.

The chained status handlers are a problem in general. I will think about a more robust solution for 1.12

I can confirm the workaround. After importing the key from Facebook everything works as expected!
Thank you very much!

Thank you very much. It helped. I can reproduce the problem now.

Same here with Mails from Facebook, here's the log

"Invalid crypto engine" Means that there is some internal error in the signature verification / decryption.

I got an Idea how to improve the situation here. But its very complex and might break Outlook even for unencrypted mails. So it's very invasive.

Right now building the release.

@nitroalex Perhaps, creating new ticker is better for this topic.
In the current OpenPGP card specification, there is no way for an application (except having a list of card implementation information) to know wich algo and which curve is supported or not.
So, what an application does is try and error.
I don't like this situation, but I don't know how we can modify the specification.

My experience is that using a string is much easier and less error prone that to build up and allocate an error obj objects. A string leads to less code and bugs are easier to detect. There are enough patter on to handle strings in a safe way and key specs are in most cases already available in string form (e.g. hex fingerprints), be it from a mail interface, as a result of a database query or from the command line.

Linux, Ubuntu

I think i can understand why this decision was made, but i'm not convinced it's a great solution. In particular, string-based arguments for C libraries are asking for trouble, and compound string arguments of the type described above are even more risky.

Is that on Windows?

The use of --textmode is in general not a good idea. The GPA on Windows will work just fine regardless of line endings. Notepad.exe also does not care about line endings as does other proper text handling software. If there is a problem c+p from the GPA "clipboard" do the system clipboard we can fix that.

Just checked. This does not seem to be a regression.

Well, I surely would agree (and this is only a proposal anyway), but my point here is, that OpenPGP Card does not support Curve 25519, so that one *have to* choose between those other two. Considering me a tinfoil hat person, I would rather not choose NIST, as many others wouldn't too.

Ok I tested with Exquilla. I configured an Exchange account once through Thunderbirds built-in account (IMAP) and once with Exquilla

In rM0adaf7bafd352f1c3a1e797493780150e3bb0adc#56272, @werner wrote:

Hey, you want to get this into 1.11.1 I assume - Let's consider this a bug fix and not another API change.

Hey, you want to get this into 1.11.1 I assume - Let's consider this a bug fix and not another API change.

Weel, you GnUPG version is actualluy the lates. Unfortunately I tested with a beta version. Let's wait a day to see whether there is more fallout and if not I will do a 1.11.1

Look like you are using an older GnuPG version and thus the test fails. I need to tweak the test.

Work is in progress, but you can already see :

• some independent changes to the build system https://github.com/gpg/gnupg/compare/master...catenacyber:fdf1ec2
• adding the code for fuzz targets and build them https://github.com/gpg/gnupg/compare/fdf1ec2...catenacyber:fd62943
• changes to gnupg code to go beyond first bugs detected https://github.com/gpg/gnupg/compare/fd62943...catenacyber:3c14d0d

I have a patch for this, but its not so good and we did not see a chance to get it upstream. For even medium sized mail accounts it already took to long as Enigmail (or better the Thunderbird Addon API) is prohibitively slow.

Thanks for the report.
I clarified the title a bit to include exchange / exquila.

Let's use the new issue as the problem is described completely there and it makes it more clear.

This was done.

No problem :).
Currently I cannot access this newer pinentry release.
My .bashrc is almost default, hence it doesn't have the line you requested.

Mh, we can probably drop the GPGME part of this. In the longer term I'm hoping for the automatic refresh in dirmngr. So that refresh-keys would not be needed.

Are you asking for a way to --refresh-keys via GPGME? IF so shall that be a syncronous thing or just a trigger. Note that we the last update time is already part of gpgme_key_t and can thus be used to check whether a trigger worked.
Anyway this will be a larger change and may need gpg support.

I already created a new issue for this in the new version of gpg4win (v3.1.0) with GpgOL v2.1.0. This is the issue: T3917.