thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.28.1 2018-05-26T14:30:32Z 2018-05-26T14:30:32Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2018-05-11T06:57:52Z urn:sha1:9088db76d89264b733f6b45e776d8952da237921 We've had _notmuch_message_database() internally for a while, and it's useful. It turns out to be useful on the other side of the library interface as well (i'll use it later in this series for "notmuch show"), so we expose it publicly now. 2018-05-15T01:18:05Z David Bremner david@tethera.net 2018-05-13T16:17:17Z urn:sha1:1883ab6650969500e5c7640ee105b386445b33e9 The performance benefits are dubious, and it's deprecated in C++11. 2017-12-08T12:08:47Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-12-08T06:24:01Z urn:sha1:29648a137c5807135ab168917b4a51d5e19e51c2 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. 2017-12-08T12:08:46Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-12-08T06:23:58Z urn:sha1:d137170b23f8ccd9f967445e101d6f694df1cad4 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. 2017-12-08T12:07:53Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-12-08T06:23:53Z urn:sha1:e4890b5bf9e2260b36bcc36ddb77d8e97e2abe7d 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. 2017-12-08T12:07:02Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-12-08T06:23:52Z urn:sha1:798aa789b5d117cf11697bc97dd982bd5a2c2ac8 Future patches in this series will introduce new policies; this merely readies the way for them. We also convert --try-decrypt to a keyword argument instead of a boolean. 2017-12-08T12:06:03Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-12-08T06:23:51Z urn:sha1:b62045a18680720b407173140d79b459e45e6039 This terminology makes it clearer what's going on at the API layer, and paves the way for future changesets that offer more nuanced decryption policy. 2017-12-05T01:48:31Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-11-30T08:59:29Z urn:sha1:a99058540823cd520cf2a5333e8ffe99799aa285 When doing any decryption, if the notmuch database knows of any session keys associated with the message in question, try them before defaulting to using default symmetric crypto. This changeset does the primary work in _notmuch_crypto_decrypt, which grows some new parameters to handle it. The primary advantage this patch offers is a significant speedup when rendering large encrypted threads ("notmuch show") if session keys happen to be cached. Additionally, it permits message composition without access to asymmetric secret keys ("notmuch reply"); and it permits recovering a cleartext index when reindexing after a "notmuch restore" for those messages that already have a session key stored. Note that we may try multiple decryptions here (e.g. if there are multiple session keys in the database), but we will ignore and throw away all the GMime errors except for those that come from last decryption attempt. Since we don't necessarily know at the time of the decryption that this *is* the last decryption attempt, we'll ask for the errors each time anyway. This does nothing if no session keys are stashed in the database, which is fine. Actually stashing session keys in the database will come as a subsequent patch. 2017-12-05T01:39:24Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-11-30T08:59:27Z urn:sha1:5f2832ae2171714dfef6d0d3302f473526480157 We will use this centralized function to consolidate the awkward behavior around different gmime versions. It's only invoked from two places: mime-node.c's node_decrypt_and_verify() and lib/index.cc's _index_encrypted_mime_part(). However, those two places have some markedly distinct logic, so the interface for this _notmuch_crypto_decrypt function is going to get a little bit clunky. It's worthwhile, though, for the sake of keeping these #if directives reasonably well-contained. 2017-10-21T22:53:19Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-10-21T02:25:41Z urn:sha1:4dfcc8c9b2e1dbb965f69283dca50c7581c88050 If we see index options that ask us to decrypt when indexing a message, and we encounter an encrypted part, we'll try to descend into it. If we can decrypt, we add the property index.decryption=success. If we can't decrypt (or recognize the encrypted type of mail), we add the property index.decryption=failure. Note that a single message may have both values of the "index.decryption" property: "success" and "failure". For example, consider a message that includes multiple layers of encryption. If we manage to decrypt the outer layer ("index.decryption=success"), but fail on the inner layer ("index.decryption=failure"). Because of the property name, this will be automatically cleared (and possibly re-set) during re-indexing. This means it will subsequently correspond to the actual semantics of the stored index.