| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
We only render the first part right now, which is not correct.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
sidebar or anything)
...so we fall back to a browser...
|
| | |
|
| |
|
|
| |
That was disabled accidentally during the port to gpgme.
|
| |
|
|
| |
As a measure against EFAIL.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Instead of manually specifying the libraries to link against and the
include directories to include we'd much rather have a single target to
link against. find_package already defines the Gpgme target for some
reason, which seems like a waste, but with the lowercase gpgme target we
can work around that problem.
|
| | |
|
| | |
|
| |
|
|
|
| |
So we can offer them for download even if displayed inline.
This is necessary for some attachments to show up from apple mail.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QGpgme and Gpgmepp are not readily available, the cmake files buggy, the
buildsystem horrendous and generally just difficult to build on windows.
Given that all they are is a wrapper around gpgme, we're better of
without all the indirections.
What we loose is:
* QGpgme moved the work to separate threads (but we then blocked
anyways), something that we can just do in our own code should we want to.
* QGpgme has a function to prettify dn's that was used to show the
signer. Also something we could bring back should we need to (don't know
where it is useful atm.)
Ported messagepart to gpgme
Almost there
Moved the crypto bits to a separate file
All gpg code is in one place.
All tests passing
Use error codes
Cleanup
|
| | |
|
| | |
|
| |
|
|
|
| |
And that keeps us from having to export stuff from the library for
windows to work.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
That makes it much more obvious where we actually rely on it.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
So we can destroy it.
|
| |
|
|
| |
This is triggered when we have encrypted+signed inline parts.
|
| | |
|
| |
|
|
| |
As inserted by autocrypt enabled clients.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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](https://isocpp.org/files/papers/n4015.pdf), 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
|
