16/b4a247fb7c5750b4fa3be50ee8eb3394515a47

   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 03D096DE8256\r
   6  for <notmuch@notmuchmail.org>; Sun, 14 Aug 2016 16:41:58 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at cworth.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.007\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.007 tagged_above=-999 required=5 tests=[AWL=0.004,\r
  12   SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=disabled\r
  13 Received: from arlo.cworth.org ([127.0.0.1])\r
  14  by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15  with ESMTP id RDVhMFu7Q6Lb for <notmuch@notmuchmail.org>;\r
  16  Sun, 14 Aug 2016 16:41:49 -0700 (PDT)\r
  17 Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197])\r
  18  by arlo.cworth.org (Postfix) with ESMTPS id CA20E6DEAEE1\r
  19  for <notmuch@notmuchmail.org>; Sun, 14 Aug 2016 16:24:10 -0700 (PDT)\r
  20 Received: from remotemail by fethera.tethera.net with local (Exim 4.84_2)\r
  21  (envelope-from <david@tethera.net>)\r
  22  id 1bZ4lM-0005JT-Ao; Sun, 14 Aug 2016 19:24:16 -0400\r
  23 Received: (nullmailer pid 13226 invoked by uid 1000);\r
  24  Sun, 14 Aug 2016 22:42:39 -0000\r
  25 From: David Bremner <david@tethera.net>\r
  26 To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>,\r
  27  Notmuch Mail <notmuch@notmuchmail.org>\r
  28 Cc: Olly Betts <olly@survex.com>\r
  29 Subject: Re: [PATCH v4 16/16] add "notmuch reindex" subcommand\r
  30 In-Reply-To: <1467970047-8013-17-git-send-email-dkg@fifthhorseman.net>\r
  31 References: <1467970047-8013-1-git-send-email-dkg@fifthhorseman.net>\r
  32  <1467970047-8013-17-git-send-email-dkg@fifthhorseman.net>\r
  33 User-Agent: Notmuch/0.22.1+61~g2ce0f13 (https://notmuchmail.org) Emacs/24.5.1\r
  34  (x86_64-pc-linux-gnu)\r
  35 Date: Mon, 15 Aug 2016 07:42:39 +0900\r
  36 Message-ID: <87h9an3rc0.fsf@maritornes.cs.unb.ca>\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: Sun, 14 Aug 2016 23:41:58 -0000\r
  52 \r
  53 Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:\r
  54 \r
  55 \r
  56 > +Supported options for **reindex** include\r
  57 > +\r
  58 > +    ``--try-decrypt``\r
  59 > +\r
  60 > +        For each message, if it is encrypted, try to decrypt it while\r
  61 > +        indexing.  If decryption is successful, index the cleartext\r
  62 > +        itself.  Be aware that the index is likely sufficient to\r
  63 > +        reconstruct the cleartext of the message itself, so please\r
  64 > +        ensure that the notmuch message index is adequately\r
  65 > +        protected. DO NOT USE THIS FLAG without considering the\r
  66 > +        security of your index.\r
  67 \r
  68 What can we say about re-indexing without the flag, when the user has\r
  69 previously indexed cleartext? I guess this is at least partly a question\r
  70 for Olly: if we delete terms from a xapian document, how recoverable are\r
  71 those terms and  positions? I suppose it might depend on backend, but\r
  72 does deleting terms provide at least same level of security as deleting\r
  73 files in modern file systems (i.e. not much against determined state\r
  74 level actors, but good enough to defeat most older brothers)\r
  75 \r
  76 > +# TODO: test removal of a message from the message store between\r
  77 > +# indexing and reindexing.\r
  78 > +\r
  79 > +# TODO: insert the same message into the message store twice, index,\r
  80 > +# remove one of them from the message store, and then reindex.\r
  81 > +# reindexing should return a failure but the message should still be\r
  82 > +# present? -- or what should the semantics be if you ask to reindex a\r
  83 > +# message whose underlying files have been renamed or moved or\r
  84 > +# removed?\r
  85 \r
  86 These tests don't seem hard to impliment, just a bit of drudge work?\r
  87 \r
  88 TBH I'd have to read source to figure out the degree of robustness\r
  89 promised by e.g. show/search for renames (without intervening new).\r
  90 There is some argument for reindexing by path as being a useful use\r
  91 case, if it could handle renames.\r
  92 \r
  93 In any case, it would be nice (TM) to document what the current\r
  94 behaviour is for users.\r
  95 \r
  96 d\r