Page MenuHome GnuPG

Kleopatra: on import own public key do not show "certify window"
Testing, LowPublic

Description

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.

Details

Version
VSD 3.1.24

Event Timeline

Please give a step-by-step description how to reproduce this.

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.

ikloecker moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.

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:

  • Kleopatra shouldn't ask questions if the same secret key is imported multiple times and it has already been marked as the user's certificate. On the other hand, Kleopatra will keep asking if a secret key belonging to a certificate without ultimate owner trust is imported repeatedly (because there is no way for Kleopatra to know if this is the first import or a repeated imported of the secret key if the public key had been imported before).
  • Kleopatra handles the import of files with a mix of public and secret keys better.
  • Kleopatra now asks for all imported secret keys if it's the user's (unless it already knows) (with a Cancel button to skip further questions).
  • Kleopatra doesn't ask the user to certify an imported public key if the user does not (yet) have any certificates they could use for certifying other certificates (i.e. they do not have any secret OpenPGP keys).

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.

ikloecker changed the task status from Open to Testing.Dec 2 2022, 11:51 AM
ikloecker removed ikloecker as the assignee of this task.
ikloecker moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.
ikloecker changed the task status from Testing to Open.Dec 15 2022, 9:44 AM
ikloecker claimed this task.
ikloecker moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.
ikloecker changed the task status from Open to Testing.Dec 15 2022, 2:47 PM
ikloecker removed ikloecker as the assignee of this task.
ikloecker moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.