thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.26 2017-12-29T20:45:46Z 2017-12-29T20:45:46Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-12-19T16:40:54Z urn:sha1:8ea4a99d74737929f58568505e41c94f65a14743 We also expand tab completion for it, update the emacs bindings, and update T350, T357, and T450 to match. Make use of the bool-to-keyword backward-compatibility feature. 2017-12-09T02:19:06Z David Bremner david@tethera.net 2017-12-09T02:19:06Z urn:sha1:040c3236afcf95bead0324a48c2e0b9cd7934993 Conflicts: NEWS Add in NEWS from point release 2017-12-09T00:35:18Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-12-08T20:09:46Z urn:sha1:cb855d8a9d24084d0965790782c1ce04b82aa9ca When i'm trying to understand a message signature, i care that i know who it came from (the "validity" of the identity associated with the key), *not* whether i'm willing to accept the keyholder's other identity assertions (the "trust" associated with the certificate). We've been reporting User ID information based on the "trust" associated with the certificate, because GMime didn't clearly expose the validity of the User IDs. This change relies on fixes made in GMime 3.0.3 and later which include https://github.com/jstedfast/gmime/pull/18. 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:46Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-12-08T06:23:55Z urn:sha1:a1260896f6b2beb82f46c41663f00cb42a4c5ce7 When showing a message, if the user doesn't specify --decrypt= at all, but a stashed session key is known to notmuch, notmuch should just go ahead and try to decrypt the message with the session key (without bothering the user for access to their asymmetric secret key). The user can disable this at the command line with --decrypt=false if they really don't want to look at the e-mail that they've asked notmuch to show them. and of course, "notmuch show --decrypt" still works for accessing the user's secret keys if necessary. 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-10-13T01:11:25Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-10-10T05:49:02Z urn:sha1:88f2a72ef1dcfce149bbac776652ea04e564726d The notmuch_crypto_t struct isn't used externally, and we have no plans to explicitly export it. Prefix its name (and associated functions) with _ to make that intent clear. 2017-10-10T01:24:02Z Jani Nikula jani@nikula.org 2017-10-07T08:44:04Z urn:sha1:0f314c0c99befea599a68bea51d759b4133efef6 C99 stdbool turned 18 this year. There really is no reason to use our own, except in the library interface for backward compatibility. Convert the cli and test binaries to stdbool. 2017-10-05T01:02:57Z Jani Nikula jani@nikula.org 2017-10-01T20:53:18Z urn:sha1:9a0df8128c1a2f92d03035aebbd7a90eb93ec601 Pedantically correct, although they're the same underlying type. 2017-10-05T01:02:09Z Jani Nikula jani@nikula.org 2017-10-01T20:53:16Z urn:sha1:ed43b8ddcd01e098a457463ceb0c0fa6b74e0a8a The --entire-thread default depends on other arguments, so we'll have to figure out if it was explicitly set by the user or not. The arg parser .present feature helps us clean up the code here.