allow indexing cleartext of encrypted messages

[Tomi Ollila]

On Fri, Dec 11 2015, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:

> On Wed 2015-12-09 22:39:37 -0500, Daniel Kahn Gillmor wrote:
>>  * the libnotmuch API is extended with
>>    notmuch_database_add_message_try_decrypt().  This should probably
>>    ultimately be more general, because there are a few additional
>>    knobs that i can imagine fiddling at indexing time.  For example:
>>
>>     * verifying cryptographic signatures and storing something about
>>       those verifications in the notmuch db
>>      
>>     * extracting OpenPGP session key information for a given message
>>       and storing it in a lookaside table in the notmuch db, so that
>>       it's possible to securely destroy old encryption-capable keys
>>       and still have local access to the cleartext of the remaining
>>       messages.
>>
>>    Some of these additional features might be orthogonal to one
>>    another as well.  I welcome suggestions for how to improve the API
>>    so that we don't end up with a combinatorial explosion of
>>    n_d_add_message_foo() functions.
>
> I have a proposal for how to do this better:
>
> I'll introduce a notmuch_index_options_t, with the usual constructors
> and destructors and a couple functions:
>
>   notmuch_index_options_set_try_decrypt()
>   notmuch_index_options_get_try_decrypt()
>   notmuch_index_options_set_gpg_path()
>   notmuch_index_options_get_gpg_path()
>
> Then i'll add:
>
>   notmuch_database_add_message_with_options(db, fname, options, &message)
>
> If we add new indexing features, they can be set directly in the
> index_options object (including features that might be more complex than
> a string or a bool, like a chain of command-line filters).
>
> a few nice features of this approach:
>
>  * The user of the library can craft a set of index options and repeat
>    it easily, and the options can contain cached/lazily-initialized
>    things (like GMimeCryptoContexts) if needed.
>
>  * The user can index different messages with different options if they
>    prefer (no need to set the options on the database object itself)
>
>  * the capability of the indexing features in the library is visible
>    directly in the exposed API.
>
> any thoughts on this?

sounds good (on paper) (*)

>
>     --dkg

Tomi

(*) deliberately declined to write 'looks good' >;) (but it's good)