thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.27 2018-05-26T14:43:30Z 2018-05-26T14:43:30Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2018-05-11T06:57:59Z urn:sha1:aa605f7e8a4c5e046503d61fdb953721c32f9d3a Add fancy new feature, which makes "notmuch show" capable of actually indexing messages that it just decrypted. This enables a workflow where messages can come in in the background and be indexed using "--decrypt=auto". But when showing an encrypted message for the first time, it gets automatically indexed. This is something of a departure for "notmuch show" -- in particular, because it requires read/write access to the database. However, this might be a common use case -- people get mail delivered and indexed in the background, but only want access to their secret key to happen when they're directly interacting with notmuch itself. In such a scenario, they couldn't search newly-delivered, encrypted messages, but they could search for them once they've read them. Documentation of this new feature also uses a table form, similar to that found in the description of index.decrypt in notmuch-config(1). A notmuch UI that wants to facilitate this workflow while also offering an interactive search interface might instead make use of these additional commands while the user is at the console: Count received encrypted messages (if > 0, there are some things we haven't yet tried to index, and therefore can't yet search): notmuch count tag:encrypted and \ not property:index.decryption=success and \ not property:index.decryption=failure Reindex those messages: notmuch reindex --try-decrypt=true tag:encrypted and \ not property:index.decryption=success and \ not property:index.decryption=failure 2018-05-26T14:39:54Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2018-05-11T06:57:57Z urn:sha1:808cababbb8ef2d1cfbf9f2babc99ba48f2b3ffa If the number of session keys for a given message increased after running "notmuch show" then we just learned something new that might let us do automatic decryption. We should reindex this message using our newfound knowledge. Amended by db: add previously discussed #if block 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.