- Key fingerprint should be shown directly in address line (at least as a tooltip) -> implemented in work/tfry/keyselection
[ ] bug: when clicking on key icon for a recipient with two candidate keys, two kleo windows pop up-> was probably a mis-observation, or I cannot reproduce. Possibly clicked twice, because initial click was handled, delayed?- bug: completion field shows source "gpg keychain". -> Changed to "Available keys" in work/tfry/connect_check_email
- provide some kind of summary in the composer window itself (e.g. will be encrypted to N keys, will be encrypted to self, will be signed)
Description
Description
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Open | tfry | T8175 Improvements to key handling / selection in composer window | ||
| Open | None | T8143 Allow to configure additional encryption keys when sending | ||
| Open | tfry | T8238 Improve selection between S/MIME and OpenPGP or both | ||
| Open | tfry | T8260 Review what is accepted as encryption key | ||
| Open | svuorela | T7724 support WKD in mail editor | ||
| Open | svuorela | T7683 allow selecting keys by ID/fingerprint for reencryption |
Event Timeline
Comment Actions
As you can see, this is the parent ticket to a bunch of smaller tasks. Work on all of them is in work/tfry/keyselection .
Review comments:
- Firstly: Sorry about the lack of modularity in the commits. I originally started out with just T8143: Allow to configure additional encryption keys when sending, but then discovered (and kept discovering) a large number of bugs and peculiarities so that I kept fixing those in between. Further, it became increasingly obvious that some sort of status summary would be desirable, and that kept evolving in parallel, as well.
- The CryptoStatusWidget (the summary display) may need some more refinements, but that's mostly a UI question, and now mostly modular in the code. The more extensive work behind the scenes should be ready for review.
- Among the bugs fixed / motivation for some of the refactoring:
- Storing selected key in the recipient line itself would cause trouble, if the recipient line is edited _after_ a key had been selected.
- config logic when using multiple email accounts was broken
- do not offer unusable keys in completion
- actually respect the key selection done in the "key approval dialog"
- Failure to show keys as resolved, if the UIDs contains upper case
- In manual resolution, setting "no key" for a recipient suggests the user will still receive the mail, while actually it was stripped, entirely, without feedback
- Bad keys would show with a green checkmark
- Keys shown in recipients line would not necessarily be the keys actually used. Esp. in case of working with mixed protocols, the choice could silently be changed on the resolver on send.
- No option to select specific keys and/or protocol, until clicking "send" (at which point manual resolution would or would not be triggered, without a way for the user to know in advance).
- Silly "oh noes" message after clicking "Cancel" in manual key resolution
- if a recipient was specified mutltiple times (with several encryption keys), the mail would not be encrypted to any keys associated with that recipient at all.