@Ainahir thanks for the info. However, your problem might be different because you are on Windows and not on Linux.
Please use for dirmngr --debug=ipc,dns instead of --debug-level=guru

Here is a file

same behavior on gpg 2.2.1

Could you please try on the command line. (If you don't know how, see: https://www.wikihow.com/Open-the-Command-Prompt-in-Windows )

The problem is still that other - non-gpgme threads - can still use getenv and friends without us noticing that. But I see no solution for this. In any case this code is the best we can do.

Hi aheinecke,
I did some tests with 2.0.7-beta10 and still found some issues.
The message I attached as a test case in previous comment is now properly handled, I see no "signature.asc" attachment and message is correctly tagged as trusted sender; this test message was sent from Evolution and I sent it to myself (sorry for not pointing this out before).

My test works now with this commit.

I think the problem is with the selction change event. When we query for selection item (1) we trigger an itemLoad event which apparently causes this behavior. I've disabled everything else in our event handling code so we don't touch the mail at all (non crypto mails we never touch much).

Thanks for the test and the example mail. Should also be fixed now.
While testing I also noticed that the sender email address was also not parsed correctly for these kind of mails and added some code to fix that.

Hello Andre.

Ok, I understand it. Project tag changed :)

GnuPG stores key in a protocol independent manner. This allows to use the same key material for ssh, X.509 and OpenPGP - if you want that. A side effect is that it is possible to use the same key material also for several subkeys. Note that, unless you use --yes, gpg-agent will issue an additional prompt to request confirmation of secret key deletion. It even will show a warning if gpg-agent knows that the key is used for ssh. The thing here is that gpg-agent is picky about accidentely deleting a secret key. In general this is better than the other way.

It's in GnuPG 2.2.4, now.

It's a bug in the OpenPGP card implementation.
I put an entry in Wiki: https://wiki.gnupg.org/SmartCard#Known_Bug.28s.29_of_OpenPGPcard

I found another issue in current master of GnuPG. Probably you already noticed it - when GnuPG AEAD-encrypts input which is a multiple of chunk size, then incorrect chunk number is used in the last block (+1)
The same happens for decryption.
Here is debug output of 128-byte input decryption with 64-byte chunk len:

gpg: DBG: nonce: D0 33 CD AC B5 54 07 66 2C 5C 55 7F A9 F2 EF
gpg: DBG: authdata: D4 01 07 02 00 00 00 00 00 00 00 00 00
gpg: DBG: nonce: D0 33 CD AC B5 54 07 66 2C 5C 55 7F A9 F2 EE
gpg: DBG: authdata: D4 01 07 02 00 00 00 00 00 00 00 00 01
gpg: DBG: nonce: D0 33 CD AC B5 54 07 66 2C 5C 55 7F A9 F2 ED
gpg: DBG: authdata: D4 01 07 02 00 00 00 00 00 00 00 00 02
gpg: DBG: eof seen: holdback buffer has the tags.
gpg: DBG: nonce: D0 33 CD AC B5 54 07 66 2C 5C 55 7F A9 F2 EC
gpg: DBG: authdata: D4 01 07 02 00 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00 80

Hi Werner,
Looks like there is a problem on my side, I miscalculated data length (0x240 while it should be 0x280).
Other then this values are the same:

Can you help me and tell me the AD for the last and the final chunk?
My current values are:

I will eventually look at this. However, sometimes the reason for such conditions can be documentation purposes. Thanks for pointing out.

With AEAD we can immediately check whether the correct passphrase is used. With CFB we can't do that and thus the checking is delayed until we can do the bulk encryption using the session key. At that point it is too late to check for other keys - well we could record that all and try again but that would make the code pretty complicate.

It was fixed with commit 641aae78 _after_ 2.2.5. Will eventually be merged into master.

@werner sorry for asking again, I may be missing something: just saw that you've marked my comment for line 259 as "done". But in master and gnupg-2.2.5 I still see the sentence as
Export the private key and the certificate identified by @var{key-id} in using the PKCS#12 format. which does not pass my English parser. :)

This is similar to T3622, but it's not the same thing.

I also struggled to get two cards running at the same time. Host system is Fedora 26 with gnupg 2.2.4.

Will go into 2.2.6

It makes --export-secret-key-p12 the recommended way to transport a privat CMS key. (fine, if this is, what was intended).
(Note that there is a typo in line 259).

I just tested version 2.0.7-beta8 x64 and I can confirm the bug is fixed, GpgOL can decrypt messages properly. Messages also appear to be properly signed.

No more info received - assuming this has been fixed after 1.2.20

Will go into 2.2.5