From: David Bremner <david@tethera.net>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>,
 Notmuch Mail <notmuch@notmuchmail.org>
Subject: Re: [PATCH v3 09/16] index encrypted parts when asked.
In-Reply-To: <1454272801-23623-10-git-send-email-dkg@fifthhorseman.net>
References: <1454272801-23623-1-git-send-email-dkg@fifthhorseman.net>
 <1454272801-23623-10-git-send-email-dkg@fifthhorseman.net>
User-Agent: Notmuch/0.21+26~g9404723 (http://notmuchmail.org) Emacs/24.5.1
 (x86_64-pc-linux-gnu)
Date: Sat, 27 Feb 2016 11:49:17 -0400
Message-ID: <87y4a640hu.fsf@zancas.localnet>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list

Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:

> 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.

I have some mild reservations about hard-coding this tagging into the
library layer, but I guess it's consistent with what is there already.
I guess we can use indexopts to control automatic tagging later.

One observation is that both index-decrypted and decryption-failed are
properties of the database state and not the message, syncing them
between machines will be a bit tricky.

> +/* descend (if desired) into the cleartext part of an encrypted MIME
> + * part while indexing. */
> +static void
> +_index_encrypted_mime_part (notmuch_message_t *message,
> +			    notmuch_indexopts_t *indexopts,
> +			    GMimeContentType *content_type,
> +			    GMimeMultipartEncrypted *encrypted_data)

Is there a good reason not to propagate crypto errors back to the
caller? It seems like it should be up to the top level caller to the
library (e.g. the CLI) to decide to ignore such errors. I'm not very
happy with tags as the only error reporting mechanism. I understand that
_index_mime_part would need to return a status value, but that change
doesn't look to disruptive?

d