thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=debian%2F0.26.2-2 2018-04-27T01:14:59Z 2018-04-27T01:14:59Z David Bremner david@tethera.net 2018-04-06T11:43:07Z urn:sha1:64831e8016fcc9877c0dc8e855ec24583cac34ef At least Fedora28 triggers this Xapian bug due to some toolchain change . https://bugzilla.redhat.com/show_bug.cgi?id=1546162 The underlying bug is fixed in xapian commit f92e2a936c1592, and should be fixed in Xapian 1.4.6 2018-04-24T02:00:20Z David Bremner david@tethera.net 2018-04-20T14:59:48Z urn:sha1:491b1f4b4082bee18418942846ec6508856be7b4 This preserves a sensible thread order 2018-04-20T14:23:31Z David Bremner david@tethera.net 2018-04-14T01:08:05Z urn:sha1:9293d6da27494d7b607c945c6678bc890749b94f Other parts of notmuch (e.g. notmuch show) expect each thread to contain at least one top level message, and crash if this expectation is not met. 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-28T14:05:55Z David Bremner david@tethera.net 2017-12-28T14:05:55Z urn:sha1:b09025bce2b795f3d49b92cb3dac437b92831321 This reverts commit 4f5bbaf7e2cecfe5022ba4b28915cccfb7ccb12d. 2017-12-26T00:40:28Z David Bremner david@tethera.net 2017-08-20T21:32:40Z urn:sha1:4f5bbaf7e2cecfe5022ba4b28915cccfb7ccb12d This change allows queries of the form thread:{from:me} and thread:{from:jian} and not thread:{from:dave} This is still somewhat brute-force, but it's a big improvement over both the shell script solution and the previous proposal [1], because it does not build the whole thread structure just generate a query. A further potential optimization is to replace the calls to notmuch with more specialized Xapian code; in particular it's not likely that reading all of the message metadata is a win here. [1]: id:20170820213240.20526-1-david@tethera.net 2017-12-21T13:22:30Z David Bremner david@tethera.net 2017-12-15T02:29:57Z urn:sha1:7cfa1c69610bcf15fb47868131d3d9102f899225 The current behaviour is at best under-documented. The modified test in T470-missing-headers.sh previously relied on printf doing the right thing with NULL, which seems icky. The use of talloc_strdup here is probably overkill, but it avoids having to enforce that thread->authors is never mutated outside _resolve_thread_authors_string. 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: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:47Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-12-08T06:24:00Z urn:sha1:6a9626a2fdddf6115bcf97982fd10053bf48e942 There are some situations where the user wants to get rid of the cleartext index of a message. For example, if they're indexing encrypted messages normally, but suddenly they run across a message that they really don't want any trace of in their index. In that case, the natural thing to do is: notmuch reindex --decrypt=false id:whatever@example.biz But of course, clearing the cleartext index without clearing the stashed session key is just silly. So we do the expected thing and also destroy any stashed session keys while we're destroying the index of the cleartext. Note that stashed session keys are stored in the xapian database, but xapian does not currently allow safe deletion (see https://trac.xapian.org/ticket/742). As a workaround, after removing session keys and cleartext material from the database, the user probably should do something like "notmuch compact" to try to purge whatever recoverable data is left in the xapian freelist. This problem really needs to be addressed within xapian, though, if we want it fixed right.