Page MenuHome GnuPG
Create Task
Maniphest T7211

Kleopatra: configuration option to prohibit deletion of certificate with secret key
Open, LowPublic
Actions

Description

In an organizational context it may be required, that a user should not be able to delete their own certificates (defined by having secret keys or key stubs), as a protection against mistakes.

New option "certificates_delete_secret".
If this option is set to "false" and

  • if a foreign certificate without secret key is selected, it still can be deleted.
  • if a certificate with with private key is selected, it can *not* be deleted. The option for deletion is greyed out.

If at least one deletable certificate has been selected when selecting several certificates, a message may appear on confirmation of the deletion indicating that some certificates cannot/may not be deleted.

The existing configuration "action/certificates_delete" should remain as is (no visual deletion option). Setting it to "false" would make the new option ineffective.

Related Objects

Event Timeline

• alexk created this task.Jul 22 2024, 3:39 PM
• alexk renamed this task from Kleopatra: configuration option to prohibit deletion of secret key to Kleopatra: configuration option to prohibit deletion of certificate with secret key.Jul 22 2024, 4:35 PM
• alexk updated the task description. (Show Details)
• aheinecke triaged this task as Low priority.Jul 22 2024, 4:49 PM
• aheinecke added a subscriber: • aheinecke.

I would give this low priority. There is no way to prohibit that except if the user has no deletion rights on the file system. There are already multiple dialogs asking the user to confirm the secret key deletion. A user could by the same logic "Free up some space" in their local home directory and delete %APPDATA%.

The only way to protect against that as an organization are backups. I think that this is out of scope for GnuPG.

Regardless, since we like to say that everything that is possible in Kleopatra could in theory be configured on and off, I do not see this as a won't fix, but not really important since it does not solve a real problem. I mean sure it is easy to say -> I accidentally delteted my secret key -> Why has the software not stopped me from that?

In that it Reminds me a bit of T6471: Kleopatra: Increase warning for backup secret key - Especially in de-vs mode and the rationale there. So maybe a similar warning here would be a better solution.

• aheinecke added a comment.Jul 22 2024, 4:56 PM

In MMO Games this is usually handled that a player either has to type in "DELETE" or type in the Characters name to delete the character. At least in the last games I played.

• aheinecke mentioned this in T4544: More prompts before key deletion.Jul 22 2024, 4:58 PM
• alexk added a comment.Jul 23 2024, 10:42 AM

Experiences from customers are that people create their certificate, upload it to a server. Then they notice a mistake in their name and delete the whole cert and upload the new one. Now there are two certificates on the server. This is only one example of what can go wrong. Admins want this not to happen and that's the reason for this feature. More warnings will probably not solve the problem.

• aheinecke added a comment.Jul 23 2024, 10:48 AM

No. To solve that problem we have the revocation certificates autogenerated in the GnuPG home folder and which are kept of course when a user deletes their key.

Its rather more likely that a user who then wants to delete their "bad certificate" searches the internet and finds that they can just delete the GNUPGHOME, in tht case the revocation certificates would be gone, too.
If the deletion is not accidental but intentional then the UI is helpless and only the operating system can prevent it.

• werner added a subscriber: • werner.Jul 23 2024, 11:45 AM

gpg makes it pretty hard to delete a secret key; thus having a (user settable) option in Kleopatra makes a lot of sense to me.

Regarding deleting of GNUPGHOME: User won't find it easily and in any case it can be restored from the backup. Oh well, we should really have a more prominent notice to create regular backups, store them on a USB stick, and put them in a VSA compliant closet.

• aheinecke added a comment.Jul 23 2024, 1:14 PM

Since Kleopatra does not suppress the pinentry prompts think there is even one additional question at least for S/MIME. So it asks you once from Kleopatra and then you are asked by GnuPG.
AFAIR we had discussed this in the past and also came up with the Idea that the user should type in DELETE. That dialog should then come from GnuPG I think so that it is the same.

But my last statement regarding the GNUPGHOME was that alexanders example was about users actually trying to delete their secrete key because they mistyped. So there an input field also won't help. And if I ask the internet "how to delete gnupg secret keys" you are told where they lie so no need to search them.

• ikloecker added a subscriber: • ikloecker.Jul 23 2024, 2:00 PM

The easiest solution would be a setting for gnupg. Then Kleopatra would just error out. But, as Andre rightfully points out, people will work around this restriction. Users are incredibly creative.

So, if an organization really cares then they should simply ACL the users' private-keys-v1.d folders so that nothing can be deleted/removed from there. Otherwise: No backup? No pity!

• alexk added a comment.Jul 23 2024, 3:53 PM

That's the way it works today in some organizations:
If users can't delete their key they are requested to ask their GnuPG admin, they actually do so and the admin does help.

Currently you can only configure not to delete any certificate using "action/certificates_delete".
This is just a request to restrict this action to deletion of certificates with private keys.