Attached the wireshark log

The workaround in T3825 is for PC/SC driver. So, it is not the case for internal stock CCID driver.
'scd reset /bye' does not let the scdaemon do reset process of the card itself. It resets the transaction of scdaemon.

Please never ever define NDEBUG. This is a severe misfeature of the assert macro.

That's exactly the point: I do want one common encryption key between the two cards: So I can distinguish between the two, but en-/decrypt with both.
One is on the GnuPG SmartCard, the other on a YubiKey - output --card-status (some things xxx'ed out) :

Here's the patch:

I contacted Microsoft Security Response Center (MSRC) in regard to this matter. They confirmed the failed PGP key verification, but have not yet any explanation for that.

Please show us your output of gpg --card-status for each card, and tell us the reason why you think "the pgp db seems screwed up".

For my test, six distinct keys (three subkeys for each smartcard) works fine.
IIUC, you try to use same decryption key by two smartcards. Currently, it is not supported.

Is it an issue when you share an decryption key E among two smartcards?
I think that when there are six distinct keys (three subkeys for one smartcard each), it works fine.
I'll try to make reproducible test case.

What are MS doing when they get it right, though? I'd look at the differences between those two to identify what they've messed up here.

Thanks. The mail is a standard, non-crypto mail with one attachment. That attachment is a TNEF file which has according to ytnef(1) just one file. That file has the name gpgolPGP.dat and contains a clearsigned message.

Sure, I zipped the eml which failed and I´ll send it by e-mail to you

Is it possible that you upload or send me a copy of such a mail (wk gnupg.org)? ZIP or tar the eml file and send it in an encrypted mail to me to make sure it won't be modified on the transport.

I checked my mails in detail, and I can confirm that the error occurs only with "Microsoft security update releases". Indeed "Microsoft security advisory notification" and "Microsoft security update summary for..." will be verified correctly.

I agree. It also happens to me. But only with mails coming from "Microsoft security update releases". Mails coming form "Microsoft security advisory notification" and Microsoft security update summary for..." are ok and are signed by the same key. It could be some trouble in MS automated email treatment.

This is mine:

Confirmed my theory of getentropy(3): https://reviews.freebsd.org/rS331279

Reading this discussion: http://lists.gnu.org/archive/html/bug-libtool/2018-01/msg00014.html
It seems that it could be fixed if we care about the order of libraries.
And it's not the issue for libgpg-error, which doesn't require external libraries.

For binutils, in Stretch, Debian specific patch was introduced.
Then, upstream introduced --enable-new-dtags option for configure to build binutils.
Now, Debian uses --enable-new-dtags option (at build time).

I think we should stick with the syscall for Linux.

FWIW, the canonical way to make sure that gpg-agent has been started is to run

You're very welcome. In my instance, this is "resolved" - I now get the prompt I realised I needed so to me this bug could be considered closed or wontfix, but I'll leave you to do with it as you please.

Basically, you are right. In addition, gpg-agent asks scdaemon about list of card/token.

OK - so if an entry is not required in sshcontrol for a smart-card key - is the private key stub sufficiently detailed enough for the agent to realise that it can ask for that card to be inserted for an ssh connection?

sshcontrol entry is required for non-smartcard keys, but not for keys on smartcard. This is intentional. For gpg-agent and current format, it is only the information for gpg-agent to know if a key is for SSH or not.

Also - going back to sshcontrol - with an ssh key added to the agent with ssh-add, an entry in sshcontrol is required - but not for a key on a smartcard. Is that intentional, or just a byproduct of the smartcard diversion that happens?

Oh, wow - yes, adding to sshcontrol brings up the prompt - I do however need to stop the agent from being restarted on insertion for it to subsequently ask for the unlock.

OpenBSD uses getentropy(2). glibc (>= 2.25) has getentropy(3), too.

Applied to master.

I see your point. You are right. For SSH access, it just fails without asking insertion. It's not Windows specific.
I checked the change of history of gpg-agent, but I cannot find prompting insertion was supported.
So, I don't thin this is a regression.

Yes, it's running. I have a scheduled task that spawns a vbscript to ensure that gpg-agent is started on login, and restarts it on insertion of a card (specifically for two reasons: windows ssh clients don't typically start agents automatically, and windows can cause gpg-agent to get a but upset after a card is removed and re-inserted. Edit: although, I think that latter reason might be resolved now... I haven't investigated deeply. more info here and here).

For the correctness of rndjent implementation, I'm applying D461: jent random requires finalizer to deallocate secure memory.

Thanks for your information.
Hum, you are using gpg-agent for SSH access.

werner,
I'm the spanish user. Are you also setting default ocsp responder option?
Setting only ocsp_signer doesn't worked, there are several CA's with diferent ocsp responders.

The reporter said that it did not work for him.