When setting up a smart card with Kleopatra you have to import your own public key after deleting the key pair.
In this case it makes no sense to ask for certification of the key.
But the "you have imported a new certificate" Window - "Do you want to certify?" pops up anyway.
Can we stop this from happening if a smart card with the corresponding secret key is connected?
Additional difficulty: quite often, Kleopatra recognizes the secret key on the smartcard only after hitting F5.
I think this is mostly an issue during the setup of smart cards because Kleopatra lacks the functionality to delete the locally stored secret key without deleting the public key. Therefore, currently, it is necessary to delete secret and public key and then to re-import the public key.
Implementing T5836: Kleopatra: Optionally, delete private key locally after moving a key to a smartcard will not fix this issue, but I think T5836 will make this issue mostly an academic problem.
I agree that this will be less important when T5836 is done. But on the other end, someone personalized a smartcard for you. Ideally when inserting the smartcard it will fetch the public key from LDAP but if that is not configured or available you will have the same case of a smartcard that creates the secret key stubs and then importing the public key. As I think that in the case of exactly one key imported a keylisting through the agent of this one key won't be that expensive we should fix this as a minor issue.
Does the problem even occur if the secret key stubs have already been created?
The original problem cannot be fixed with a simple keylisting because no part of gnupg knows anything about the key (except maybe scdaemon?), neither about the secret part nor the public part, after the entire key has been deleted. Maybe gpg should remember that even though it has just deleted the secret key locally the secret key is still on some smart card. I mean just seconds ago gpg copied the secret key to the smart card, so it should know that the secret key is still available even though it has been removed locally. Of course, this would make it impossible to make gpg forget about keys stored on smart cards. Hmm. Or does gpg know this? But without public key gpg will list nothing even if there is a secret key stub.
If the keys on the smart card are already known to Kleopatra/GnuPG (which should be the case if the smart card was inserted when Kleopatra was started), then on import of the corresponding public key Kleopatra now asks whether the certificate is the user's certificate (instead of asking whether they want to certify it).
Additionally, a few other changes/fixes have been made:
Last, but not least, a possible crash when importing multiple files was fixed. It's possible that this crash didn't happen before the changes because Kleopatra asked less questions.
The following works, too:
The rest is not objectively testable