With new "KEYINFO" command of scdaemon, finally, we can move on to support better selection of signing key.
(Note: having a private key on multiple cards had already been solved in T4301: Handling multiple subkeys on two SmartCards.)

In master, it has been implemented.

The first "SCD SERIALNO" command let scdaemon re-scan smartcards/tokens.

With new "KEYINFO" command in scdaemon, a list of card keys can be retrieved by:

There is no use cases for $SIGNKEYID.

$ENCRKEYID use case have been removed.

Fixed and backported.

You may.. Comments were relevant. Bye.

FWIW, the GTK and QT pinentries do have a qualitybar. However is is only enabled:

I agree.

Err.. Just removing the check may be the correct fix; It doesn't make sense to limit capability here.

At least one configuration error I could identify by myself: Kleopartra -> GnuPG-System -> Smartcard -> Connecting Reader with port N. If it is written: Yubico YubiKey OTP+FIDO+CCID 0 then Yubikey is recognized. I forgot to write "Yubico Yubikey" at the beginning and the "0" at the end. Now smart cards and Yubikeys are working for gpg. What is still a problem is SSH. A SSH key is on smart card or the Yubikey.

The base64 for the version is not needed. I rebuilt and did a test for that. I was testing with Outlook 2016 to Outlook.com to another exchange server. One of the servers in the chain is converting the mime parts to base64.
The MAPI headers in gpgol are causing the auto-decryption of Symantec to stop checking for the MIME attachments. On internal emails the MAPI format is retained and that causes an issue with the symantec client. When they leave the exchange server the base MIME format is what is sent and that works with the Symantec client.

In T4809#131931, @werner wrote:

BTW, the qualitybar is not shown by default, only if you configure sme of the extra password checks. We may even remove it completely because it leads to wrong assumption on why a passphrase is required.

@Rycky_Tigg cases 1, 2, and 3 that you document here each show the behavior that i would expect from pinentry-gnome3, given the definition of its Assuan-based API and its use of gcr-prompter. (i'm assuming that in case 3 the user just waited longer than the allowed timeout)

Thank you for resolving this issue! I am successfully using version 2.2.19 from the gnupg (2.2.19-1~bpo10+1) package of Debian Backports.

"more specific about what you think is wrong"; From https://bugs.kde.org/show_bug.cgi?id=412569 copied)/pasted:

I think rGe573e6188dad: gpg: Fix --default-key checks. should be fixed as:

diff --git a/g10/getkey.c b/g10/getkey.c
index ad5dd8e01..cc908964e 100644
--- a/g10/getkey.c
+++ b/g10/getkey.c
@@ -1860,7 +1860,8 @@ parse_def_secret_key (ctrl_t ctrl)
           PKT_public_key *pk = node->pkt->pkt.public_key;

$ export GNUPGHOME=<somewhere>
# Create a key with "C"-only capability
$ gpg --quick-gen-key "test-user <chuji@gniibe.org>" ed25519 cert
# Create another key (or get/import it)
$ gpg --quick-gen-key "2020-user <chuji2020@gniibe.org>" ed25519
# Sign with the first key to the second key with --default-key
$ gpg --default-key 7694AB44DED1154CEB981059B0B36418AF85C918 --lsign 72FF31542DB059A507BAF81BE05523DEB4B018E6

(where 7694AB...85C918 is the first key and 72FF31..B018E6 is the second key)

rGe573e6188dad: gpg: Fix --default-key checks. is suspicious.

BTW, the qualitybar is not shown by default, only if you configure sme of the extra password checks. We may even remove it completely because it leads to wrong assumption on why a passphrase is required.

pinentry-gnome uses gcr's gcr_prompt_set_password_new to prompt for a new password, and ignores the SETQUALITYBAR assuan command.

It seems that gnome-keyring-daemon has some incompatible changes which breaks that version of pinentry-gnome. Or GKR has not been setup properly. I'd suggest to use pinentry-gtk until folks with knowledge about Gnome folks have figured out what is going wrong.

Hey. As reference – Complete set of features while run in Windows.

Please describe which features are missing.

Caching of the OpenPGP PIN while switching to and from PIV does now work in master

Using base64 encoding for a fixed format part in us-ascii is not a good idea because in practise many PGP/MIME decoders won't be able to detect and then decyrypt such a message.

$AUTHKEYID use cases have been removed.

Werner, no silly questions exist, only silly answers are existing. However, Yubikey is enabled for usb. I using Yubikey Manager a GUI, for the USB interface it is enabled: OTP, FIDO, FIDO U2F, OpenPGP, PIV and OATH. Thanks also for the suggested command line test. Indeed an error code shows up:

It is a feature not a bug. For symmetric encryption the gpg-agent remembers the passphrase used for the encryption and thus for some time or until /gpgconf --reload gpg-agent/ it tries that passphrase for decryption.

I am wondering if there is any workaround or work in progress about this old ticket.
I understand this is kind of an edge case, but having the possibility to use signed ssh keys would be very useful to me.

Maybe a silly question, but let's be sure: Is the Openpgp app enabled on that Yubikey and is it enabled for usb? I can't remember the Yubikey commands on how to check this but tehre should even be a GUI. These days I use the new gpg-card tool to manage my Yubikeys (from GnuPG master).

Please, note the following uncommon behavior:

I'll keep this on needs triage because I don't know what the issue could be. I have a yubikey 5 at hand and just tested it with Gpg4win 3.1.11. It works without problems.

note that it *does* sometimes hide the legacy display part, for some messages, including unfortunately-complex -- that's good! -- but maybe this points to some internal inconsistency:

Sorting the table is a good idea for reproducibility, since otherwise the tree depends on the order of the arguments to asn1-gentables, which are generated with a wildcard expansion that might be shell or file system dependent.

I removed the footnote form the 2.2 branch. Thanks.

Frankly, I am not sure why we sort that table at all. Your patch does not harm, though.

FWIW, the second listed commit is the right one. You should only look at the STABLE-STABLE-2-2 branch. master and that branch differ; in particular we do not have a cut-off date in master (to be 2.3).

No need to support it. What I had in mind was the compilation of tiger.c where we replace optimization flags by -O1 which, as you remarked, seems to b widely portable.