Thanks for testing. I guess I will do a new release.

Standard behaviour for stdio functions.

For master (2.3) the fix is not needed due to another way the code works, but having a more robust function is always good.

You may try the above commit - if should apply cleanly to 2.2.37.

You are right. This due to your old binary private key (stubs). Otherwise you would at least have one item ("Key:"). I need to see what do do about the release. Maybe a tool to update the key files would we a good workaround.

Oh well, why do I receive such bug reports right after the next release :-(

Small correction: We don't have replicas of our code signing key. I mistook this with out Authenticode signing key.

In general I use my standard ed25519 signing token for all software. However, GnuPG VS-Desktop is signed using a Brainpool key named GnuPG.com (stored on a smartcard with 2 replicas) for the simple reason that it does not raise questions when ppl update their GnuPG VS-Desktop and run into a non-compliant key.

This looks like a different but not too uncommon problem. For T6169 we need to get a PKCS#12 file to be able to replicate the problems - obviously that PKCS#12 should hold only test keys/certs.

It turned out that this is pretty important if you use a current version of scute; That one uses gpg-connect-agent to list all smartcards. And gpg-connect-agent will start and take over a remote socket used for the card.

You get this error because the key has been created in gnupg mode (and not in de-vs) and thus it has these preferences.

Let's turn this into a feature request.

I think we can close this one. Note also that we now have --no-user-trustlist and --sys-trustlist-name. in 2.2.37 and 2.3.7 which allows to entirely ignore the user trustlist and to define a global one..

@dkg: Thanks for the detailed description of the problem.

I added this option on 2005-07-19 and iirc this was planned for the FSFE's rig to produce their membership cards. I kept that option in 2.0 for backward compatibility but it does not make any sense because its gpg-agent's duty to ask for cards - gpg does not known about it.

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 ;-)