From fb73271e25895759e20001798cd28f094a7e307c Mon Sep 17 00:00:00 2001 From: David Bremner Date: Sun, 28 Feb 2016 11:49:17 +2000 Subject: [PATCH] Re: [PATCH v3 09/16] index encrypted parts when asked. --- 51/d81fa9e13324f9469a6328b8075186a3067ed7 | 87 +++++++++++++++++++++++ 1 file changed, 87 insertions(+) create mode 100644 51/d81fa9e13324f9469a6328b8075186a3067ed7 diff --git a/51/d81fa9e13324f9469a6328b8075186a3067ed7 b/51/d81fa9e13324f9469a6328b8075186a3067ed7 new file mode 100644 index 000000000..59416c177 --- /dev/null +++ b/51/d81fa9e13324f9469a6328b8075186a3067ed7 @@ -0,0 +1,87 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by arlo.cworth.org (Postfix) with ESMTP id A1B706DE0FFA + for ; Sat, 27 Feb 2016 07:49:23 -0800 (PST) +X-Virus-Scanned: Debian amavisd-new at cworth.org +X-Spam-Flag: NO +X-Spam-Score: -0.036 +X-Spam-Level: +X-Spam-Status: No, score=-0.036 tagged_above=-999 required=5 + tests=[AWL=-0.025, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] + autolearn=disabled +Received: from arlo.cworth.org ([127.0.0.1]) + by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id uqTo2G7NA52f for ; + Sat, 27 Feb 2016 07:49:21 -0800 (PST) +Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197]) + by arlo.cworth.org (Postfix) with ESMTPS id 76DAC6DE0FB0 + for ; Sat, 27 Feb 2016 07:49:21 -0800 (PST) +Received: from remotemail by fethera.tethera.net with local (Exim 4.84) + (envelope-from ) + id 1aZh83-0000Ca-I4; Sat, 27 Feb 2016 10:49:59 -0500 +Received: (nullmailer pid 26748 invoked by uid 1000); + Sat, 27 Feb 2016 15:49:17 -0000 +From: David Bremner +To: Daniel Kahn Gillmor , + Notmuch Mail +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 +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.20 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Sat, 27 Feb 2016 15:49:23 -0000 + +Daniel Kahn Gillmor 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 -- 2.26.2