The PKCS#12 import was a late add-on because I consider P#12 to be a nasty and insecure format. Unfortunately it survived and is now the mainly used interchange format. Eventually we need to improve things here. However, ppl should use smartcards for S/MIME.

We have a cancel button and an cancel-all button (Window close button). The former skips the current key the latter should cancel the entire decryption process.

Needs to be forward ported to master

If you use an IP address there is no server name and thus a) TLS can't check the name and b) virtual servers won't work. But as you stated this is not the problem: With rGb231959728a0056 (T2924) https is handled in another way than hkps.
Now, that change was only applied to KS_GET and not to KS_SEARCH. This is kind of correct but shows this surprising behaviour: For the preferred keyserver we really want to do a plain fetch and don't have all the hkp ip/name mapping we do.

The delays are due to /usr/sbin/laptop_mode from the laptop-mode-tools package.

Inserting as well as removal is detected on my machine always only after 25 seconds

Right, this is only for the OPENPGP cards. Meanwhile we have
a way to get information on the supported algorithms. For example:

I went back to 2.3.3 and it seems it never worked as I expected. But we should understand the reason for the long delay.

I am fine with that. No need for the WoT bells and whistles

Okay, the mentioned patch does not help. I now tried the actual use
case of mine, which is to ssh without the token plugged in. I clicked
two times OK, then inserted the token and then I had to click
around dozen times onto OK before the inserted card was detected.

The interesting thing is that I did not changed my box but it "suddenly" started to misbehave. Thus I conclude this is a matter of our own changes. The log I sent you by PM was done with my suggested improvement (npth_unlock/lock around libusb_get-device_list) and it might actually helped a bit - I am not sure. I will test again w/o that change. Or maybe I should bisect.

I tried with no success.

Did you test with a self-signed cert? I ran into the problem that the selection only showed the root certificate, the signing works using the leaf cert, but the root cert was put into the signature. Changing Scute to only return the leaf certificate made it work but verification failed.

I imported the public key using Kleopatra.

It will be a lot of work to change this in gpg. Thus ISO dates were only introduced with gpgsm after the former glibc maintainer refused to switch to a 64 bit time_t - which would have been easy enough at that time (about the year 2001).

Yes, I removed them accidentally because they were listed under the keyserver option heading in gpg. They actually belong below the import/export heading.

ACS readers simply don't work reliable under Linux.

There is a reason that we switched to ISO Date strings in large parts of GnuPG ;-)

Here is an example

If the stub has been created or updated we will now ask for the card
with the Display-SN. If in addition a Label has been set to the key
that label is also shown. Note that the Display-S/N is associated wit
a card but the Label is associated with a key. For example if the
same key has been stored on two cards, the prompt will ask for one of
those cards but shows the same same Label. It is sufficient to insert
any of the cards with the key because that is what we actually need.

In master we already have Token lines which are created but not yet used. I am going to extend this with the display S/N and drop the idea of a separate Display-SN entry.

I am going to introduce a new DisplaySN: value for 2.2 which might also be useful for master.

We have changes for this in master; I need to see whether it is possible to backport them.

Here is an example on how to remove the AEAD preference from a key using GnuPG 2.3:

As an alternative you may change the preferences on the key to adjust them to your changed/downgraded version.

While playing with your scripts I figured that it would be useful to enhance the KEYINFO command. With
rG989eae648c8f3d2196517e8fc9cce247b21f9629 we could now

FWIW, the man pages do not carry all the info we have. However, I plan to chnage this and put everyting into man pages. It turned out that even me uses the man pages more than info(1) or gnupg/doc/*.

We are currently investigating another problem with a new feature. Thus things are delayed. Hopefully we get a new release this month (or at least a new gnupg 2.3 version to install on top of gpg4win).

Should go into 1.10 too

Firefox nicely shows the 3 NIST certificates from my Telesec card but not the important Brainpool certificate for eIDAS. It turns out that Firefox does not support Brainpool, despite that a patch has been provided 8 years ago. See https://bugzilla.mozilla.org/show_bug.cgi?id=943639 . Thus there is currently no way to use LibreOffice or Okular to signe PDFs because they rely on NSS.

With my patch I see the expected status message:

The problem seems to be that we don't return a status code with the
actual error via the --command-fd interface: