saturneric / GpgFrontend

A free, open-source, robust yet user-friendly, compact and cross-platform tool for OpenPGP encryption. It stands out as an exceptional GUI frontend for the modern GnuPG (gpg).
https://gpgfrontend.bktus.com
GNU General Public License v3.0
473 stars 46 forks source link

Shouldn't UIDs and subkeys be revoked instead of simply deleted? #162

Open kuolemaaa opened 1 month ago

kuolemaaa commented 1 month ago

Sorry for this issue, I'm trying to learn gpg and openPGP and also I'm being weirded out looking at the differences between the other GUI frontends of gpg. I really like your sleek interface but there is something that bugs me out.

As title: should a secondary User ID be revoked instead of deleted? Or maybe the application tells me delete for the fact that I did not upload my keypair in any keyserver? Kleopatra lets me revoke them instead of deleting and, still, lists the revoked ones with the valid ones, as it should, I think.

But I tell you again: I'm a openGPG beginner so I don't really know

Another weird thing is: Seahorse (GNOME gpg frontend) lets me revoke a single subkey optionally specifying a reason for it and I think that's good, the revoked ones stay there marked. On the other hand there is no way to revoke or delete subkeys in GpgFrontend (nor in Kleo) and also it does not inform me that a subkey were revoked. The revoked subkey is just there untill I restart it.

saturneric commented 1 month ago

Thanks for using this software. I am maintaining and developing it in my spare time, and all some of the details of the functionality are not particularly well-developed. But I will continue to improve it through user feedback, so your feedback is very important to me. Because it is also difficult for me as a developer to use all the features of GpgFrontend frequently in my spare time and then find problems.

First of all, about UID, according to the design logic of UID, it really shouldn't be removed, but revoked.

Also, the "Let the user add the reason for revocation of the key" is a perfect reminder, as I hadn't considered that revocation could have such additional information.

I'll work on both of your suggestions later. I'll continue to follow up on this Issue, and if you have any other questions, feel free to ask, I'd be happy to interact with you.