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

I changed the wording to suggest the use of proper transport security.

Thank you. With that message I could reproduce the problem and have a fix. I now get to decryption failed / no secret key as it should be.

hm, i think this is the file:

You can find the message attached.
Message has been saved from Outlook 2013.

Thanks for your report and analysis.

Thanks for tracking this down. I'll fix.

Bissecting between gnupg-2.3-base and master pinpointed commit ecbbafb88d920e713439b6b1b8e1b41a6f8d0e38 as the origin of the bug. This commit changed MAX_FINGERPRINT_LEN from 20 to 32, but the get_user_id_byfpr function in g10/getkey.c still assumes the old value.