Okay, I now got such a patch:

I found a good enough solution: I changed the code to compute the OpenPGP s/n from the Yubikey s/n right after a Yubikey has been detected. Later, and if OpenPGP enabled on the YK, the S/N is already there but we use the S/N from the 0x4f DO. That is needed because we can't compute the OpenPGP version number ahead and use 0.0 in the S/N.

Released on 2020-11-18

Note that if you run into problems with a smartcard you should run "gpg --card-status" once. GUI frontends usually do that and this is the reason why this regression was not detected. Will be fixed in 2.2.25 (T5140).

Removing 2.2 tag because it has been fixed in one of the last releases.

Its done for 2.2 thus changing the tag.

As @dkg noted T4592 is a duplicate of this and given that we have a mitigation in place we can also close this (older) bug.

Thanks.

Before step 2.d you should stop gpg-agent and other daemon

This was fixed in 2.2.24 with commit rG7f765a98fd662

If you want to debug this, I suggest to use a logging socket. Put into all gpg-agent.conf files these lines:

I though about this too but we need to take care about the logging functions of Libgcrypt which are intertwined with nPth (clamp function of libgpg-error).

Right, our installation really needs an update. It is not gnupg.org mail but just the mails from phabricator - which unfortunately does not use our standard mail system

Urgs, that was my fault.

We had some card related regressions in 2.2.23. I would appreciate if you could first test again with 2.2.24 which was released yesterday.

I am sorry, but this is not a help desk but a bug tracker. See https://gpg4win.org or https://gnupg.org to find out which community support is available.

It was a bunch or work and we are still not able to pass Unicode strings on the command line. Will eventually be done. At least people in Asia can now use their regular Windows account with gpg.

Yes sure. --debug ipc should give you some insight why gpg does not thing the key is on the card.

Ingo, can you please check? I guess we are not affected because Kleo already checks for an empty string. But dkg's suggestion sounds good to me.

A fix has been released; see T5052.

I change this to a feature request: Allow several processes to run public key decryption using the same set of private keys.

Note that you actually run 30 independent processes with gpg 1.4 but with gpg-agent there is just one process to handle the private key operations (decrypt). To utilize more cores you need to setup several GNUPGHOME with the same private keys.

I know these troubles.

Please ask on a mailing list - this is a bug tracker and somehow expects bug descriptions.

Sorry, I do not understand what kind of bug you are trying to report. it seems that you have a question about some software and you assume this is gpg4win. "invalid pocket" is however not an error any of our software emits.

BTW, the idea is to fade out support for gpg --card-status and --card-edit. Thus no new features there. New features shall only go into gpg-card.