thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.26.2 2018-04-02T11:06:53Z 2018-04-02T11:06:53Z David Bremner david@tethera.net 2018-03-27T21:30:28Z urn:sha1:920f5d925eee09d41d5c6456701854ad6d342d95 We added several new functions, at least notmuch_database_get_default_indexopts notmuch_database_index_file notmuch_indexopts_destroy notmuch_indexopts_get_decrypt_policy notmuch_indexopts_set_decrypt_policy notmuch_message_count_files notmuch_message_has_maildir_flag notmuch_message_reindex notmuch_message_remove_all_properties_with_prefix notmuch_thread_get_total_files 2017-12-08T12:08:47Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-12-08T06:24:02Z urn:sha1:fccebbaeef1e4b6489425afb13f419543d53d285 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. 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-10-21T22:53:08Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-10-21T02:25:40Z urn:sha1:0bb05ff693737c5b91d6a64f6209984a6c418c46 This allows us to create new properties that will be automatically set during indexing, and cleared during re-indexing, just by choice of property name. 2017-10-21T22:52:47Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-10-21T02:25:38Z urn:sha1:20ff9de24de47e591dd45e7dde0ac10948d6cbf6 This is currently mostly a wrapper around _notmuch_crypto_t that keeps its internals private and doesn't expose any of the GMime API. However, non-crypto indexing options might also be added later (e.g. filters or other transformations). 2017-10-20T10:58:43Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-10-17T19:09:59Z urn:sha1:0b9e1a2472e50bd56a5e269d51aa729a4290a92a Subsequent patches will introduce a convention that properties whose name starts with "index." will be stripped (and possibly re-added) during re-indexing. This patch lays the groundwork for doing that. 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. 2017-09-24T12:15:24Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-09-23T14:46:13Z urn:sha1:e3a6368e8d57baf41e779a525839a9bd0f3363a8