From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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