[PATCH v2 15/16] added notmuch_message_reindex

This new function asks the database to reindex a given message, using the supplied indexopts. This can be used, for example, to index the cleartext of an encrypted message. --- lib/message.cc | 91 +- lib/notmuch.h | 14 + 2 files

[PATCH v2 12/16] add --try-decrypt to notmuch new

Try to decrypt any encrypted parts of newly-discovered messages while indexing them. The cleartext of any successfully-decrypted messages will be indexed, with tags applied in the same form as from notmuch insert --try-decrypt. If ~/.notmuch-config contains crypto.gpg_path, and gpg is needed for

[PATCH v2 13/16] add indexopts to notmuch python bindings.

Make notmuch indexing options are not available in python as the notmuch.Indexopts class. Users can do something like: import notmuch d = notmuch.Database() indexopts = notmuch.Indexopts(try_decrypt=true) d.add_message(fname, indexopts=indexopts) --- bindings/python/notmuch/__init__.py |

[PATCH v2 11/16] add --try-decrypt to notmuch insert

allow an incoming message to be delivered while indexing the cleartext. This requires the secret keys for the message to be available. For the moment, the most functional approach is to ensure that gpg-agent is running and knows about any secret keys that might be useful to decrypt incoming

Allow indexing cleartext of encrypted messages (v2)

This is the second draft of the series initially announced in id:1449718786-28000-1-git-send-email-...@fifthhorseman.net: > Notmuch currently doesn't index the cleartext of encrypted mail. This > is the right choice by default, because the index is basically > cleartext-equivalent, and we

[PATCH v2 04/16] Provide _notmuch_crypto_{set,get}_gpg_path

Use functions to access the gpg_path for a _notmuch_crypto_t object. This lets us return sensible defaults based on the state of the user's machine. --- notmuch-reply.c | 13 ++--- notmuch-show.c | 12 ++-- util/crypto.c | 49 -

[PATCH v2 08/16] reorganize indexing of multipart/signed and multipart/encrypted

This prepares the codebase for a cleaner changeset for dealing with indexing some encrypted messages in the clear. --- lib/index.cc | 39 +++ 1 file changed, 19 insertions(+), 20 deletions(-) diff --git a/lib/index.cc b/lib/index.cc index f166aef..ab0fd78

[PATCH v2 09/16] index encrypted parts when asked.

If we see index options that ask us to decrypt when indexing a message, and we encounter an encrypted part, we'll try to descend into it. If we can decrypt, we tag the message with index-decrypted. If we can't decrypt (or recognize the encrypted type of mail), we tag with decryption-failed.

[PATCH v2 03/16] make shared crypto code behave library-like

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. --- lib/database.cc | 6 ++ lib/notmuch.h | 17 + mime-node.c | 7 ++- util/crypto.c | 55

[PATCH v2 01/16] add util/search-path.{c, h} to test for executables in $PATH

This is a utility function we can use to see whether an executable is available. --- util/Makefile.local | 2 +- util/search-path.c | 55 + util/search-path.h | 24 +++ 3 files changed, 80 insertions(+), 1 deletion(-)

[PATCH v2 02/16] Move crypto.c into libutil

This prepares us for using the crypto object in both the library and the client. i've prefixed notmuch_crypto with _ to indicate that while this can be built into the library when needed, it's not something to be exported or used externally. --- Makefile.local | 1 - crypto.c|

[PATCH v2 07/16] create a notmuch_indexopts_t index options object

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 to indexopts (e.g. filters or other transformations). --- lib/Makefile.local| 1 +

[PATCH v2 10/16] Add n_d_add_message_with_indexopts (extension of n_d_add_message)

Expose the ability to ask for index options via the library interface. This _add_message_with_indexopts function is now a generalized form of the older _add_message. It lets you specify parameters and configurations that can affect the indexing, like indexing encrypted messages in the clear

[PATCH v2 16/16] add "notmuch reindex" subcommand

This new subcommand takes a set of search terms, and re-indexes the list of matching messages using the supplied options. This can be used to index the cleartext of encrypted messages with something like: notmuch reindex --try-decrypt \ tag:encrypted and not tag:index-decrypted ---

[PATCH v2 14/16] test indexing cleartext version of delivered messages.

This requires a bit of reorganization: * add_gnupg_home gets moved to test-lib.sh, and * we allow passing --long-arguments to "notmuch new" via emacs_fcc_message --- test/T350-crypto.sh | 15 --- test/T355-index-decryption.sh | 42

[PATCH v2 05/16] Use a blank _notmuch_crypto to choose the default gpg_path

This way we're only choosing a default in one place. --- notmuch-config.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/notmuch-config.c b/notmuch-config.c index d252bb2..7cd19a7 100644 --- a/notmuch-config.c +++ b/notmuch-config.c @@ -418,7 +418,8 @@ notmuch_config_open

[PATCH v2 06/16] Prefer gpg2 in the test suite if available

Now that the notmuch client prefers gpg2 if available, having the test suite use the same preference makes it more likely to validate as expected. Be warned that the final test in T350-crypto.sh fails with an infinite loop in gpg if you're using an unpatched GnuPG 2.1.10, due to an upstream GnuPG

Re: Bug#812003: emacs24-el: message-mode repeats non-deterministic cryptographic operations in Fcc when sending

Over in https://bugs.debian.org/812003 On Tue 2016-01-19 23:26:21 -0500, Daniel Kahn Gillmor wrote: > When composing a message with an Fcc: line in emacs message-mode, if > the message has any cryptographic operations set on it > (e.g. mml-secure-message-sign-pgpmime, or >

Re: [PATCH v1] emacs: Allow part preferences to depend on message content.

Hi David, 2016ko urtarrilak 15an, David Edmondson-ek idatzi zuen: > > Currently the preference for which sub-part of a multipart/alternative > part is shown is global. Allow to the user to override the settings on a > per-message basis by providing two new options: > > - the ability to call a

Re: [PATCH v1] emacs: Allow part preferences to depend on message content.

On Tue, Jan 19 2016, Aaron Ecay wrote: > This code is not compatible with lexical binding in emacs >= 24, which I > assume notmuch will eventually want to adopt. What’s so bad about > writing a function? I would be fine with that - I was just exploring alternatives.