thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.28.2 2018-05-26T14:33:01Z 2018-05-26T14:33:01Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2018-05-11T06:57:56Z urn:sha1:bc842bfff12998a9b1a30b880cf8c6612f727d45 If the decryption policy is NOTMUCH_DECRYPT_TRUE, that means we want to stash session keys in the database. Note that there is currently no way from the command line to set it this way, though, so it is not yet included in the test suite. 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-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-12-05T01:39:13Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-11-30T08:59:26Z urn:sha1:9beda4b9811323d1fd9eb120d6e7a2ef69beed14 If (for whatever reason) we don't get a decrypt_result back, or it's not structured the way we expect it to be, we shouldn't choke on it. 2017-11-06T00:25:54Z David Bremner david@tethera.net 2017-11-06T00:25:54Z urn:sha1:7ac96b149f5a0e5c03b64856d7c20789dab3c628 Changes from 0.25.2 release 2017-11-05T19:41:13Z Jani Nikula jani@nikula.org 2017-10-16T15:40:44Z urn:sha1:cd3f5e1a934b9952ca718e0c5bc1471b3884020c Commit 1fdc08d0ffab ("cli/crypto: treat failure to create a crypto context as fatal.") started treating crypto context creation failures "as fatal", returning NULL from _mime_node_create(). Unfortunately, we do not have NULL checks for _mime_node_create() failures. The only caller, mime_node_child(), could check and return NULL (as it's documented to do on errors) but none of the several call sites have NULL checks either. And none of them really have a trivial but feasible and graceful way of recovery. So while the right thing to do would be to handle NULL returns properly all over the place, and we have other scenarios that do return NULL from above mentioned functions, the crypto context creation failure is something that does seem to show up regularly in some scenarios, revert back to the functionality before commit 1fdc08d0ffab as an interim fix. 2017-10-20T10:58:20Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-10-17T19:09:56Z urn:sha1:a18bbf7f155369f251b0513788eade23be3555d5 If we're going to reuse the crypto code across both the library and the client, then it needs to report error states properly and not write to stderr.