For GnuPG 2.2, it's better to be conservative (least change of behavior, if any).

My proposal is applying SOS (MPI with leading zero octets) patches, for 2.2, because there may be existing keys with SOS already.

It's not yet solved.

I guess this is solved. Feel free to re-open and schedule for 2.2.34

Might be a TOR Thing?

Sure there are logs, see the options log-file and debug in the man pages.
To sign using specific subkey or the main key, use the fingerprint of the key and append an exclamation mark.
For example

I put my initial try by rG752422a792ce: scd: Select a reader for PC/SC..

I found this: https://gist.github.com/PatrickLang/7be00ba46a43eca3ef64ffe64b494749#user-content-conflicts-with-windows-hello--virtual-smart-card

Yes, but it is more complicated to do because you need to download a binary version of the keys and check that they are authentic. Most users don't known it. Anyway, I meanwhile created a Brainpool release sign key and new VSD releases are signed with that. The override option does not really harm, but we can close this bug due to the new release key.

Wouldn't it be safer to use gpgv for verifying the signature than to add a code path to gpg to circumvent the hard de-vs compliance check?

On my new Windows 10 laptop I see a "Windows Hello for Business 1". Thus put everything with "Windows Hello" at the end of the list or skip unless a reader-port is set. IIRC there are device with "virtual" or "Virtual" in their name, they don't make sense for us either. I would also put devices with "SCM" or "Identiv" to the top of the list. In particular the substrings "SPR532" seems to identify the Identiv SPR332 which is what we use here and actualay a suggested reader for GnUPG VS-Desktop.

Please tell me reader names to skip.

There won't be any other 3.1 release - install GnuPG 2.2.32 on top of Gpg4win 3.1.16

My experience on a Window 10 system (with Gpg4win 3.1.15 which has GnuPG 2.2.27) was, that removing the expired root certificate did not help with https://keyserver.ubuntu.com and the intermediate certificate was not in the windows store, so it could not be removed.

Removing an intermediate cert from your local system doesn't help because any correctly configured server will send you all necessary intermediate certs together with the server cert. You'd have to remove the expired root certificate instead (see Workaround 1 on https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/). The problem is that this will break certificate verification for any servers that still use the old intermediate cert, e.g. keyserver.ubuntu.com.

The LE web site has instruction on how to do this. However, it is complicated and depends on your system. The intermediate cert you listed is signed by the expired old root cert. If you remove this intermediate cert the other root cert will be found and we are done. The old LE certs had a 4 tier chain and the new one a 3 tier.
See https://dev.gnupg.org/rG341ab0123a8fa386565ecf13f6462a73a137e6a4 and https://letsencrypt.org/images/isrg-hierarchy.png

One problem I see is that keyserver.ubuntu.com delivers a problematic intermediate(?) certificate:

If there is no easy way to install a new version of GnuPG, e.g. for Gpg4win or for GNU/Linux distributions: It may make sense to have instructions for the workaround ready.

Please update to 2.2.32 if you have problems with keyservers etc.

Backported to 2.2.32

We have been hit by the Let's Encrypt root cert switch. Thus a fixed version will soon be released. See T5639 for details of the problem.

You mean Gpg4win. The solution for Gpg4win 3.1.x is to install the latest GnUPG LTS installer for Windows on top of the latest Gpg4win version. See
https://lists.gnupg.org/pipermail/gnupg-announce/2021q3/000464.html
Noet that there will very soon be a 2.2.32 to fix a problem with Let's encrypt protected keyservers (T5639).

Just for everbody else who might be waiting for a new release. Workaround is to simply use the previous version: https://www.gpg4win.de/change-history-de.html (3.1.15)

Hey, are there any other logs that I can grab? Is there a way to override the defaults, which will allow me to use the right key to sign?

Tried and no change -- cmd window still flashes away.

Remember to always pass --batch for unattended operations.

Thanks to jaclaz@msfn.org, the workaround is to use pipe operation like:
pause|"C:\Program Files\GnuPG\bin\gpg.exe" --verify "%1"
He also confirmed that gpg.exe does interrupt batch processing, regardless what command is followed.
And I have tested in Windows 7, batch processing is not interrupted. Since this bug is WindowsXp specific, "won't fix" should be more proper.

I introduced a regression in this version; if you run into problems please update to 2.3.31 (T5571)

Won't be implemented as a new option because --check-sym-passphrase-pattern and --check-passphrase-pattern (since 2.2.30) can be used to implement the same in a more flexible way.

gniibe: What's the state of this?

Currently I see no need to fix this for 2.2

Released with 2.2.30 (T5519)

Sorry, GnuPG proper has no context menu or any graphic user interface. You need to install Gpg4win for this. Regarding use of gpg by other programs: There has been no change - other programs need to use the status-fd/command-fd interface and that has always been defined as UTF-8 and not as any native codepage. Please ask the makers of The Bat what is going wrong there.

I verified that manually putting the DB in WAL mode also resolved this issue, since writers don't block readers in WAL mode.

I think this issue is solved. For systemd, I need to run this as --supervised option not the --daemon option. The --daemon option has bug.

I think this behaviour has something to do with "attached signature"?!

I tried applied the bulk of the patch to 2.2 but w/o reading the key creation time from the card. We don't have the supporting code for latter in 2.2. However this does not make sense. Users should switch to 2.3 if they needs this feature.

Will do.

To fix this, rG48251cf9a7d3: gpg: Improve generation of keys stored on card (brainpool,cv25519). for GnuPG 2.3 should be backported.

So it is related to code page. Screenshots may be more informative:

Frankly, I don fully understand your report. Can you please clarify?
Note that with 2.2.8 we introduced full Unicode support on the command line. If you see scrambled output you may want to "chcp 65001" to get the output correctly rendered.

I have done tests with 2.2 and no problems showed up.