notmuch/util/crypto.c, branch 0.29

util/crypto: add information about the payload part

2019-05-29T11:02:45Z

When walking the MIME tree, if we discover that we are at the cryptographic payload, then we would like to record at least the Subject header of the current MIME part. In the future, we might want to record many other headers as well, but for now we will stick with just the Subject. See https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html#cryptographic-envelope for more description of the Cryptographic Payload vs. the Cryptographic Envelope. Signed-off-by: Daniel Kahn Gillmor

util/crypto: _notmuch_message_crypto: tracks message-wide crypto state

2019-05-26T11:20:23Z

E-mail encryption and signatures reported by notmuch are at the MIME part level. This makes sense in the dirty details, but for users we need to have a per-message conception of the cryptographic state of the e-mail. (see https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html for more discussion of why this is important). The object created in this patch is a useful for tracking the cryptographic state of the underlying message as a whole, based on a depth-first search of the message's MIME structure. This object stores a signature list of the message, but we don't handle it yet. Further patches in this series will make use of the signature list.

util/crypto: improve comment

2019-05-07T09:41:28Z

The comment line here lingers from when we were using some fancy version checking about session keys. Correct it to match the current state. Signed-off-by: Daniel Kahn Gillmor

gmime-cleanup: drop all arguments unused in GMime 3

2019-05-03T09:56:38Z

This means dropping GMimeCryptoContext and notmuch_config arguments. All the argument changes are to internal functions, so this is not an API or ABI break. We also get to drop the #define for g_mime_3_unused. signed-off-by: Daniel Kahn Gillmor

gmime-cleanup: always support session keys

2019-05-03T09:55:32Z

Our minimum version of GMime 3.0 always supports good session key handling. signed-off-by: Daniel Kahn Gillmor

gmime-cleanup: remove obsolete gpg_path configuration option and crypto contexts

2019-05-03T09:55:04Z

Note that we do keep ignoring the gpg_path configuration option, though, to avoid breakage of existing installations. It is ignored like any other unknown configuration option, but we at least document that it is ignored so that people who find it in their legacy configs can know that it's safe to drop. signed-off-by: Daniel Kahn Gillmor

crypto: add --decrypt=nostash to avoid stashing session keys

2017-12-08T12:08:47Z

Here's the configuration choice for people who want a cleartext index, but don't want stashed session keys. Interestingly, this "nostash" decryption policy is actually the same policy that should be used by "notmuch show" and "notmuch reply", since they never modify the index or database when they are invoked with --decrypt. We take advantage of this parallel to tune the behavior of those programs so that we're not requesting session keys from GnuPG during "show" and "reply" that we would then otherwise just throw away.

crypto: actually stash session keys when decrypt=true

2017-12-08T12:08:47Z

If you're going to store the cleartext index of an encrypted message, in most situations you might just as well store the session key. Doing this storage has efficiency and recoverability advantages. Combined with a schedule of regular OpenPGP subkey rotation and destruction, this can also offer security benefits, like "deletable e-mail", which is the store-and-forward analog to "forward secrecy". But wait, i hear you saying, i have a special need to store cleartext indexes but it's really bad for me to store session keys! Maybe (let's imagine) i get lots of e-mails with incriminating photos attached, and i want to be able to search for them by the text in the e-mail, but i don't want someone with access to the index to be actually able to see the photos themselves. Fret not, the next patch in this series will support your wacky uncommon use case.

crypto: record whether an actual decryption attempt happened

2017-12-08T12:08:46Z

In our consolidation of _notmuch_crypto_decrypt, the callers lost track a little bit of whether any actual decryption was attempted. Now that we have the more-subtle "auto" policy, it's possible that _notmuch_crypto_decrypt could be called without having any actual decryption take place. This change lets the callers be a little bit smarter about whether or not any decryption was actually attempted.

crypto: new decryption policy "auto"

2017-12-08T12:07:53Z

This new automatic decryption policy should make it possible to decrypt messages that we have stashed session keys for, without incurring a call to the user's asymmetric keys.