Page MenuHome GnuPG

Kleopatra: Optionally, delete private key locally after moving a key to a smartcard
Closed, ResolvedPublic

Description

A common use case with Kleopatra is to move a key to a smartcard:

  • Create key
  • Move the key to card
  • Make a backup of the public key
  • Delete the key (private and public)
  • Import the public key
  • Set the imported key again to ultimately trusted.

Unfortunately we need to handle the key stubs at least with GnuPG 2.2. This requires that one first needs to hit F5 in the card dialog (which creates the stub but does not give any visual feedback) and then hit F5 in the key listing so that the imported will be marked as having the private key. Only then the key may be marked as ultimately trusted.

Not everyone known when to hit F5.

It would also be possible to add an option to remove only the private key - this would in fact be easier to understand for the user. Maybe by collecting the moved (sub)keys and finally offer to delete their copies.

Update 2022-04-19: As discussed, the destructive operation to delete the private key should be confirmed by the user by entering some text, e.g. "delete".

Update 2022-11-25: Deleting the secret key needs to be confirmed with the usual confirmation dialog (as in all other cases where the user request the deletion of a secret key) and not by entering some text.

Event Timeline

werner triaged this task as Normal priority.Feb 16 2022, 5:29 PM
werner created this task.

It should not really hurt to query the scdaemon again after an import. We can do this in the background and users wont have to notice it in the general case where imports from others happen.

So form my side it would be ok to just schedule a readstatus update in an importresult.

In Kleopatra's KeyToCardCommand there is this comment

/* TODO DELETE_KEY is too strong, because it also deletes the stub
 * of the secret key. I could not find out how GnuPG does this. Question
 * to GnuPG Developers is pending an answer

before a commented out code snippet that asks the user whether the key should be deleted locally and, if the user confirms, asks the agent to do DELETE_KEY --force <keygrip of subkey>.

(Re)Activating this code snippet would save the user the above long list of manual steps. All that is missing seems to be a READKEY --card --no-data -- <keyRef> after the DELETE_KEY to get the stub created (and maybe reloading the key list).

ikloecker renamed this task from Reload key list after a key has been moved to a smartcard to Kleopatra: Optionally, delete private key locally after moving a key to a smartcard.Apr 19 2022, 11:01 AM
ikloecker updated the task description. (Show Details)

For the record, I am for the deletion as long as it is guarded by a safety check.

The danger I see is that moving the key to the smartcard failed and we miss the error (as happened before) and thus the key is deleted without an existing copy on the smartcard. I think this is probably the reason why this was commented out when our smartcard support was less mature.

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.Nov 25 2022, 12:34 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.

This is now ready for testing.

Note that I didn't make it extra hard to delete the secret key. The user can make a backup ("No backup, no sympathy!") and Kleopatra double-checks that the smart card (or at least scdaemon) reports the expected key.

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

But I'd like to comment in general on the subject if this workflow really is a simplification. I think it is still rather complicated.

After discussing with Andre, I suggest a button in the details window for moving all subkeys of the key to the attached smart card.
The normal user is not interested in subkeys, probably does not know that there are subkeys, they want to move "the" key to the card.

After clicking that "move to card" button I would prefer that a backup would be offered first and after that the transfer and delete/not delete handled in a second window.

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

The options for key backup+delete, delete and keep all work now, tested with VS-Desktop-3.1.27.0-beta44

The usability issues are addressed in T6116.