51/d81fa9e13324f9469a6328b8075186a3067ed7

   1 Return-Path: <david@tethera.net>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5  by arlo.cworth.org (Postfix) with ESMTP id A1B706DE0FFA\r
   6  for <notmuch@notmuchmail.org>; Sat, 27 Feb 2016 07:49:23 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at cworth.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.036\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.036 tagged_above=-999 required=5\r
  12  tests=[AWL=-0.025, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01]\r
  13  autolearn=disabled\r
  14 Received: from arlo.cworth.org ([127.0.0.1])\r
  15  by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16  with ESMTP id uqTo2G7NA52f for <notmuch@notmuchmail.org>;\r
  17  Sat, 27 Feb 2016 07:49:21 -0800 (PST)\r
  18 Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197])\r
  19  by arlo.cworth.org (Postfix) with ESMTPS id 76DAC6DE0FB0\r
  20  for <notmuch@notmuchmail.org>; Sat, 27 Feb 2016 07:49:21 -0800 (PST)\r
  21 Received: from remotemail by fethera.tethera.net with local (Exim 4.84)\r
  22  (envelope-from <david@tethera.net>)\r
  23  id 1aZh83-0000Ca-I4; Sat, 27 Feb 2016 10:49:59 -0500\r
  24 Received: (nullmailer pid 26748 invoked by uid 1000);\r
  25  Sat, 27 Feb 2016 15:49:17 -0000\r
  26 From: David Bremner <david@tethera.net>\r
  27 To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>,\r
  28  Notmuch Mail <notmuch@notmuchmail.org>\r
  29 Subject: Re: [PATCH v3 09/16] index encrypted parts when asked.\r
  30 In-Reply-To: <1454272801-23623-10-git-send-email-dkg@fifthhorseman.net>\r
  31 References: <1454272801-23623-1-git-send-email-dkg@fifthhorseman.net>\r
  32  <1454272801-23623-10-git-send-email-dkg@fifthhorseman.net>\r
  33 User-Agent: Notmuch/0.21+26~g9404723 (http://notmuchmail.org) Emacs/24.5.1\r
  34  (x86_64-pc-linux-gnu)\r
  35 Date: Sat, 27 Feb 2016 11:49:17 -0400\r
  36 Message-ID: <87y4a640hu.fsf@zancas.localnet>\r
  37 MIME-Version: 1.0\r
  38 Content-Type: text/plain\r
  39 X-BeenThere: notmuch@notmuchmail.org\r
  40 X-Mailman-Version: 2.1.20\r
  41 Precedence: list\r
  42 List-Id: "Use and development of the notmuch mail system."\r
  43  <notmuch.notmuchmail.org>\r
  44 List-Unsubscribe: <https://notmuchmail.org/mailman/options/notmuch>,\r
  45  <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  46 List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
  47 List-Post: <mailto:notmuch@notmuchmail.org>\r
  48 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  49 List-Subscribe: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
  50  <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  51 X-List-Received-Date: Sat, 27 Feb 2016 15:49:23 -0000\r
  52 \r
  53 Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:\r
  54 \r
  55 > If we see index options that ask us to decrypt when indexing a\r
  56 > message, and we encounter an encrypted part, we'll try to descend into\r
  57 > it.\r
  58 >\r
  59 > If we can decrypt, we tag the message with index-decrypted.\r
  60 >\r
  61 > If we can't decrypt (or recognize the encrypted type of mail), we tag\r
  62 > with decryption-failed.\r
  63 \r
  64 I have some mild reservations about hard-coding this tagging into the\r
  65 library layer, but I guess it's consistent with what is there already.\r
  66 I guess we can use indexopts to control automatic tagging later.\r
  67 \r
  68 One observation is that both index-decrypted and decryption-failed are\r
  69 properties of the database state and not the message, syncing them\r
  70 between machines will be a bit tricky.\r
  71 \r
  72 > +/* descend (if desired) into the cleartext part of an encrypted MIME\r
  73 > + * part while indexing. */\r
  74 > +static void\r
  75 > +_index_encrypted_mime_part (notmuch_message_t *message,\r
  76 > +                         notmuch_indexopts_t *indexopts,\r
  77 > +                         GMimeContentType *content_type,\r
  78 > +                         GMimeMultipartEncrypted *encrypted_data)\r
  79 \r
  80 Is there a good reason not to propagate crypto errors back to the\r
  81 caller? It seems like it should be up to the top level caller to the\r
  82 library (e.g. the CLI) to decide to ignore such errors. I'm not very\r
  83 happy with tags as the only error reporting mechanism. I understand that\r
  84 _index_mime_part would need to return a status value, but that change\r
  85 doesn't look to disruptive?\r
  86 \r
  87 d\r