Diffusion Kube d5b5c33a0cb3

Automatic key import / export + Expected monad

Authored by rnicole on Mar 9 2018, 12:32 PM.

Description

Automatic key import / export + Expected monad

Summary:
There are many things going on here (perhaps a bit much for a single patch):

  • When an attachment is of mime type "application/pgp-keys", a button is added to import the key to GPG
  • When sending a mail and crypto is enabled (encryption, signing or both), the public key of the first private key found is sent as an un-encrypted attachment (T6994)
  • The mailcrypto.{h,cpp} was, for the most part, rewritten
  • Introduction of the expected monad, inspired by what was proposed for C++ here, but not at all a strict implementation of this specification. We may want to add some more features of this standard later.

The rationale for some of the choices:

  • I found mailcrypto a bit hard to edit to add new features, and a great part was commented code to prepare for the support the SMIME crypto format, which would (in my current knowledge) not be used for sending emails.
  • One thing I found that may be missing in the code base was a standardized way of handling errors in C++ code. Since exceptions are disabled I think that the functional way is the way to go. After some research I found the Expected monad / tagged union / sum type, which seemed to suit the problem particularly well.

In the long run, I hope we would move the entire code base to use Expected to indicate if a function might fail.

Of course every choice made here is to be considered as a proposition for doing things / RFC, critics wholeheartedly accepted.

Reviewers: cmollekopf

Tags: Kube

Maniphest Tasks: T6994, T8147, T6995

Differential Revision: https://phabricator.kde.org/D11158

Details

Committed
cmollekopfMar 9 2018, 12:32 PM
Differential Revision
D11158: Automatic key import / export + Expected monad
Parents
R162:93e9c10d1894: Avoid coloring the text blue on blue background.
Branches
Unknown
Tags
Unknown