Page MenuHome GnuPG
Create Task
Maniphest T6198

KMail: Port to keyresolver from libkleo
Open, NormalPublic
Actions

Description

When I started with the keyresolver for GpgOL I had the idea to use the same resolver in KMail and GpgOL. But I never got around to working on that. The API should be similar enough and I explicitly included the mutliple format support for KMail as I think at least for some users the possibility to send PGP/Inline to some contacts is important and this could even be a feature in the future of GpgOL.
It was also the reason why I initially had the "nagging" in API of the keyresolver as KMails Keyresolver also checks for expiry dates of used certificates etc. Something like that would be useful for GpgOL, too.

Anyhow. Since we have the group support now in Kleopatra and in the keyresolver this is more important as that is a killer feature which is often requested. So I add the gpgcom tag as this work would benefit both GpgOL and KMail.

Related Objects
Search...

Event Timeline

• aheinecke triaged this task as Wishlist priority.Sep 9 2022, 1:50 PM
• aheinecke created this task.
• aheinecke mentioned this in T6330: Kleopatra: Additional Expiry handling.Jan 5 2023, 11:21 AM
• aheinecke added a parent task: Unknown Object (Maniphest Task).Jan 24 2023, 12:48 PM
• ikloecker removed a parent task: Unknown Object (Maniphest Task).Apr 24 2023, 12:14 PM
• ikloecker closed subtask T6467: KMail: Replace usage of NearExpiryChecker with new ExpiryChecker as Resolved.Jun 2 2023, 1:38 PM
• aheinecke added a subtask: T6566: GpgOL: newly generated key not loaded in the security confirmation dialog.Jul 3 2023, 12:05 PM
• aheinecke added a comment.Jul 4 2023, 2:00 PM

Another request for this would be that the for expired keys a --locate-key might be triggered. GpgOL currently does this in internal logic and this causes GnuPG to refetch the key e.g. from WKD if the key came originally from WKD. https://bugs.kde.org/show_bug.cgi?id=471911 I am not sure if the expiry checker already does this, but someone pointed me to the KDE bug and I will point back here because it makes little sense to fix this in the kmail resolver when we want to replace it.

• ikloecker added a subscriber: • ikloecker.Jul 5 2023, 11:01 AM

The expiry checker checks for expiry. It doesn't and shouldn't do anything else.

• aheinecke raised the priority of this task from Wishlist to Normal.Jul 24 2023, 9:15 AM
• aheinecke added subscribers: dvratil, • alexk.

I realized again how bad the current implementation is last week when Alexander managed to send a mail to me encrypted with a completely unrelated key.
a) It was not clear to him that he encrypted to a totally different key because it only displays the keyid
b) He somehow managed to store that key for me in the addressbook
c) He again selected something like "always encrypt to this user" in the dialog without realizing the consequences. This created a contact for me in his personal address book (invisible to him because he said he does not use the addressbook and in there all sources were unselcted) which had the wrong keyid (again only the fingerprint there) and the setting "always encrypt to this user"

Especially c) is a problem. I regularly have to remove the crypto settings in our Addressbook because even our employees tend to check them with good intentions like "do not bring up this dialog again but just encrypt".
c) Is especially horrible since the crypto settings for the addressbook are a plugin, which is not installed by default on most systems. So just setting the checkbox basically breaks KMail for unsuspecting users. Since they have no idea how to remedy this. And if you send a Mail to say 15 People and have "always encrypt to this user" checked for one of them. Well,.. its bad.

I don't want to remove the address book options. In fact the options "always encrypt to this domain" or "always encrypt to this mail address" are much requested in Outlook. And to put arbitrary keys in the addressbook is nice. I would even like to see it extended but that is a different issue. For just putting keys into the Address book the new keyresolver has this "overrides" system especially in place for them and it works file with outlooks address book. And users like the setting "always encrypt to this user" but it should IMO be more like a "always encrypt to this user if possible". The new keyresolver could come up and just show "hey you only have keys for some users, do you wish to continue with encryption and others will be unable to read them" or "send unencrypted for all" something like that.

The features to send different crypto formats like S/MIME opaque to some, S/MIME to others, PGP/Inline to some and PGP/MIME to others can just die. We support S/MIME and OpenPGP and the selected protocol is defined by the certificate from the Address book.

I added dan to the subscribers but Ingo since you worked on the new resolver already for a bit I think you are better suited for the task. I am promoting this from wishlist to "normal" even though it still is a wish but I like to see this done sooner rather then later.

• ikloecker changed the status of subtask T6566: GpgOL: newly generated key not loaded in the security confirmation dialog from Open to Testing.Nov 16 2023, 1:23 PM
dvratil added a comment.Nov 19 2023, 8:42 PM

Just my five cents:

c) Is especially horrible since the crypto settings for the addressbook are a plugin, which is not installed by default on most systems

Considering that Privacy is part of KDE's vision and "Secure" is literally the first feature we list on KMail web page, I think we could have a fairly strong argument to bring this particular plugin back into KAddressbook, to be always present.

The kdepim-addons split, honestly is a pain for PIM maintainers as many reports and complaints from the users come from the fact they don't have the package installed and the applications brake unexpectedly, especially in the less-tested parts.

• werner closed subtask T6566: GpgOL: newly generated key not loaded in the security confirmation dialog as Resolved.Sep 26 2024, 3:16 PM