thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.28.4 2018-06-25T00:59:37Z 2018-06-25T00:59:37Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2018-06-19T22:36:16Z urn:sha1:fd3c93650d976f630ba0a60341a1a695422e4969 Many of the manpages didn't treat literal text as literal text. I've tried to normalize some of the restructured text to make it a bit more regular. several of the synopsis lines are still untouched by this cleanup, but i'm not sure what the right way to represent those is in .rst, actually. In particular find that if i rebuild the manpages, sometimes i end up with some of the synopsis lines showing – (U+2013 EN DASH) where they should have -- (2 × U+002D HYPHEN-MINUS) in the generated nroff output, though i have not tracked down the source of this error yet. 2018-05-07T11:42:53Z David Bremner david@tethera.net 2018-05-05T15:59:28Z urn:sha1:f2e6f76a046492650713c1c3f1f1a19f49de59ea Mention both performance and quoting issues. 2018-04-25T02:08:10Z David Bremner david@tethera.net 2018-04-07T22:10:51Z urn:sha1:20ba0b7dfae2111f76d71c8d695265014c2ef7c5 I think we've diverged enough from the Xapian query parser that we can't rely on that syntax description [1]. As far as I can tell, [1] also only discusses quotes in the context of phrases. [1]: https://xapian.org/docs/queryparser.html 2018-03-24T23:07:20Z Matthew Lear matt@bubblegen.co.uk 2018-02-06T21:52:01Z urn:sha1:0cbe982bfd4516ee441ca5bbdd858616e54cc141 Need to be clearer about specifying time ranges using timestamps. Legacy syntax which predates the date prefix is still supported, but timestamps used in conjunction with the date prefix require additional syntax. 2017-12-31T13:06:11Z Jani Nikula jani@nikula.org 2017-12-30T17:16:11Z urn:sha1:e5e252de5560fee386bd46f8f279c800b953c667 Make all parameter descriptions etc. use reStructuredText definition lists with uniform style and indentation. Remove redundant indentation from around the lists. Remove blank lines between term lines and definition blocks. Use four spaces for indentation. This is almost completely whitespace and paragraph reflow changes. 2017-12-15T01:41:39Z Jani Nikula jani@nikula.org 2017-11-02T20:01:17Z urn:sha1:89f651a40374d07750528f45d555ce821c049c80 Having first a list of prefixes followed by detailed descriptions was viable when we didn't have all that many prefixes. Now, arranging the prefix descriptions in a definition list makes more sense. While at it, include all the supported prefix forms, especially some missing regex ones. 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:56Z urn:sha1:f845fb2a51f87dfa60388d65ac481ba21556bb78 The stashed session keys are stored internally as notmuch properties. So a user or developer who is reading about those properties might want to understand how they fit into the bigger picture. Note here that decrypting with a stored session key no longer needs -decrypt for "notmuch show" and "notmuch reply". 2017-12-08T12:05:53Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-12-08T06:23:50Z urn:sha1:d3964e81ac98825a025a6120c488ebd73de2a281 the command-line interface for indexing (reindex, new, insert) used --try-decrypt; and the configuration records used index.try_decrypt. But by comparison with "show" and "reply", there doesn't seem to be any reason for the "try" prefix. This changeset adjusts the command-line interface and the configuration interface. For the moment, i've left indexopts_{set,get}_try_decrypt alone. The subsequent changeset will address those. 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.