Debian's wiki also speaks a lot about the advantages & dream of subkeys, but also mentions the caveat:

I've read many articles mentioning the improved key handling when different devices just have different subkeys, thus allowing a semantic connection to a primary identity (instead of different "Identities" on different devices)

Ooops: You need to put

Well it makes sense to me in that KEYTOCARD explicitly is not documented but the semantics between keytocard in edit key and KEYTOCARD in agent should be the same IMO. As you can imagine I am also not a fan of the fact that GnuPG changed behavior here, but the "keep / delete" is even with GnuPG 2.3 not really an option as GnuPG might replace the real key with the stub depending on how it is called anyhow. So this is dangerous for us to "suggest" from the UI that the key will be kept and then it might be removed without actions by Kleopatra. So this must be changed.

Arguing with the documentation of a functionality Kleopatra doesn't make use of makes no sense. Kleopatra uses gpg-agent's "KEYTOCARD" command which, unfortunately, lacks a good documentation.

works if you use a valid IP address

In T6383#167887, @werner wrote:

You need write access to the usb device (e.g. /dev/bus/usb/001/011) or you install pcscd and put "disable-ccid-driver" into scdaemon.conf.

Oh sorry I only saw this now. We have "gpgme_set_offline" for this use case which disables CRL checks in the S/MIME case. It is more general because it also disables OCSP for example and might disable more online actions like fetching chain certificates etc.

So as I understand this:

Okay, gpg2 --card-status is accessible using sudo/su.
But I still don't know why bumping from 2.2.41 to 2.4.0 the use of pcsc-lite + ccid stopped work.

I can't access even trying using root.
pcsc-lite was already installed. I tried using disable-ccid-driver as advised but didn't help, scd.log don't even get written using this option.

Ready for testing. In case of a file name conflict the users are now offered to Overwrite the existing file or to Rename the new file (i.e. save it with a different name). If multiple output files are created (e.g. when encrypting multiple files separately), then the users are additionally offered the options "Overwrite All", "Rename All", "Skip", "Skip All".

What do you want to achieve by using multiple encryption subkeys? Do you realize that gpg will always encrypt to one subkey (unless you explicitely specify multiple subkeys), i.e. you won't be able to decrypt on device 1 what you have encrypted for device 2 and vice-versa. Usually, this makes little sense because it seems you want to be able to decrypt anything on your main machine.

You need write access to the usb device (e.g. /dev/bus/usb/001/011) or you install pcscd and put "disable-ccid-driver" into scdaemon.conf.

The application probably doesn't support this curve, the changelog only mentions Curve25519 and NIST P-256. Also Kleopatra lists only these two curves when generating a key from the card. Upon further inspection, the 0xFA DO listing the supported algorithms only has RSA 2048, RSA 4096, nistp256, ed255519 and cv25519

This is a Nitrokey 3A with the firmware 1.2.2-alpha.20221130. I'll check with the vendor.

Sure that you specific card/implementation of Nitrokey supports this curve? The card application uses a vendor from the test card range - this it is likely that it is some Javacard implementaion or it is an old gnuk firmware on the nitrokey basic.

Changing the key attributes didn't help unfortunately:

There must be some regression in the code which changes the key attributes. Please try
"gpg --card-edit" admin, key-attr
and switch to nistp384.

I also tried to import the key with the gpg-card writekey command and I got the same error.

Same error message but probably a different cause, in this case the card was factory reset before importing.

Looks similar to T6378. Can you provide the output of

Thanks for the reply :)

Sorry, I think you have to fix the other tools. The ! suffix has virtually been supported forever and any new option to do the same complicates the code and the documentation.

well, this user made a backup and it went wrong anyway ;-) See T6377

Oh this issue was in the wrong project. Related to T5836

If 3.1.26 only offers RSA algos, then Kleopatra obviously assumes that the smart card only supports RSA and therefore doesn't offer the transfer of Brainpool keys.

I'm sorry, I got a bit confused, it works in Kleopatra on 3.2.0, but not in 3.2.26

Which algorithms are offered when you use "Regenerate Key"? What's the output of gpg -K --with-colon <key_id>?

Thanks. please give a few days.

created ~/.gnupg/gpg-agent.conf containing:

debug ipc,cache
debug-pinentry
log-file socket://

Okay, I see. The commands above are a real reproducer and not standalone examples. Then yes, you should get a pinentry only for the first gpg -d (as long as the keys are still in the cache). I am lacking macOS/homebrew stuff to replicate this. What you can do is to put

Kleopatra simply copies the content of the corresponding *.key file in the private-keys-v1.d folder. If the *.key file contains a shadowed key after issuing a KEYTOCARD --force [...] command followed by a SCD LEARN --force command (note the SCD!), then gpg-agent is to blame.