ec/125622e01d39e5e6eb9620a3ca239ebc35386b

   1 Return-Path: <dkg@fifthhorseman.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 olra.theworths.org (Postfix) with ESMTP id 644DF40DBC8\r
   6         for <notmuch@notmuchmail.org>; Tue, 16 Nov 2010 12:07:13 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -1.899\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5\r
  12         tests=[BAYES_00=-1.9, UNPARSEABLE_RELAY=0.001] autolearn=ham\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id QMGgvUSC215U for <notmuch@notmuchmail.org>;\r
  16         Tue, 16 Nov 2010 12:07:02 -0800 (PST)\r
  17 Received: from rodolpho.mayfirst.org (mail.freitas.net [209.234.253.107])\r
  18         (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))\r
  19         (No client certificate requested)\r
  20         by olra.theworths.org (Postfix) with ESMTPS id DC68F40DDCB\r
  21         for <notmuch@notmuchmail.org>; Tue, 16 Nov 2010 12:07:01 -0800 (PST)\r
  22 Received: from localhost (localhost [127.0.0.1])\r
  23         by rodolpho.mayfirst.org (Postfix) with ESMTP id 5F1CB3CD51\r
  24         for <notmuch@notmuchmail.org>; Tue, 16 Nov 2010 15:06:58 -0500 (EST)\r
  25 X-Virus-Scanned: Debian amavisd-new at rodolpho.mayfirst.org\r
  26 Received: from rodolpho.mayfirst.org ([127.0.0.1])\r
  27         by localhost (rodolpho.mayfirst.org [127.0.0.1]) (amavisd-new,\r
  28         port 10024) with ESMTP id mBgswJ46eZUX for <notmuch@notmuchmail.org>;\r
  29         Tue, 16 Nov 2010 15:06:58 -0500 (EST)\r
  30 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender:\r
  31         smtpauth@rodolpho.mayfirst.org) with ESMTPSA id 17BFB3CD4C\r
  32 Message-ID: <4CE2E45C.7080206@fifthhorseman.net>\r
  33 Date: Tue, 16 Nov 2010 15:06:52 -0500\r
  34 From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>\r
  35 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;\r
  36         rv:1.9.2.9) Gecko/20100918 Icedove/3.1.4\r
  37 MIME-Version: 1.0\r
  38 To: notmuch <notmuch@notmuchmail.org>\r
  39 Subject: Re: a proposed change to JSON output to report verification of\r
  40         PGP/MIME signatures.\r
  41 References: <4CDE4486.2050101@fifthhorseman.net>\r
  42         <87hbfhdpa6.fsf@yoom.home.cworth.org>\r
  43 In-Reply-To: <87hbfhdpa6.fsf@yoom.home.cworth.org>\r
  44 X-Enigmail-Version: 1.1.2\r
  45 OpenPGP: id=D21739E9\r
  46 Content-Type: multipart/signed; micalg=pgp-sha512;\r
  47         protocol="application/pgp-signature";\r
  48         boundary="------------enigD73B070CC388B68353460BAC"\r
  49 X-BeenThere: notmuch@notmuchmail.org\r
  50 X-Mailman-Version: 2.1.13\r
  51 Precedence: list\r
  52 Reply-To: notmuch <notmuch@notmuchmail.org>\r
  53 List-Id: "Use and development of the notmuch mail system."\r
  54         <notmuch.notmuchmail.org>\r
  55 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  56         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  57 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  58 List-Post: <mailto:notmuch@notmuchmail.org>\r
  59 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  60 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  61         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  62 X-List-Received-Date: Tue, 16 Nov 2010 20:07:13 -0000\r
  63 \r
  64 This is an OpenPGP/MIME signed message (RFC 2440 and 3156)\r
  65 --------------enigD73B070CC388B68353460BAC\r
  66 Content-Type: text/plain; charset=UTF-8\r
  67 Content-Transfer-Encoding: quoted-printable\r
  68 \r
  69 On 11/16/2010 02:47 PM, Carl Worth wrote:\r
  70 > The current linearization of parts is a bug that should be fixed. And I=\r
  71 \r
  72 > think several aspects of your proposal are effectively workarounds for\r
  73 > this bug. So I'd rather we fix the json output to emit the tree\r
  74 > structure first, and then see what parts of the proposal can be\r
  75 > eliminated.\r
  76 >=20\r
  77 > [And I think David Edmondson's reply said the same as above, but with\r
  78 > more detail. Right?]\r
  79 \r
  80 ok, good to know.  that makes sense to me, and i'll plan my work around\r
  81 the idea of future tree-structured output.  i didn't know whether the\r
  82 linearized output was considered a feature or not.  tree-structured\r
  83 output makes me happier.\r
  84 \r
  85 > The only other piece I think I'd like to see is actually making the\r
  86 > content of the signature pieces available in the json output. Then, a\r
  87 > client could do its own verification.\r
  88 \r
  89 once we have tree-structured output, we'd only need to be able to\r
  90 request a literal byte-stream of any mime-part.  so if the mime parts\r
  91 were structured this way:\r
  92 \r
  93 1=E2=94=94=E2=94=AC=E2=95=B4multipart/signed 80029 bytes\r
  94 2 =E2=94=9C=E2=94=AC=E2=95=B4multipart/mixed 78178 bytes\r
  95 3 =E2=94=82=E2=94=9C=E2=95=B4text/plain 699 bytes\r
  96 4 =E2=94=82=E2=94=94=E2=95=B4text/plain attachment [a_dancing_monkey.png]=\r
  97  76978 bytes\r
  98 5 =E2=94=94=E2=95=B4application/pgp-signature attachment [signature.asc] =\r
  99 892 bytes\r
 100 \r
 101 then the client would need to be able to extract a clean (untampered,\r
 102 internal-headers included) copy of part 2, to verify against the\r
 103 signature found in part 5.\r
 104 \r
 105 Note that "notmuch part" currently emits only the content of the emitted\r
 106 parts.  it strips off the internal mime headers, and apparently does\r
 107 some form of content mangling too (base64 decoding, etc).  this is\r
 108 unacceptable for the purposes of signature verification.  Maybe notmuch\r
 109 part needs a --unfiltered flag or something?\r
 110 \r
 111 Note also that clients that are willing and able to parse mime\r
 112 structures themselves can already do the signature verification\r
 113 themselves by fetching the whole thing with --format=3Dmbox.\r
 114 \r
 115 > Then if we had that would we not want to add the --verify support into\r
 116 > notmuch? (My guess is that we still would want it.)\r
 117 \r
 118 i think it's a good idea to enable verification on the backend, because\r
 119 we don't want to force each frontend author to reinvent the wheel.  I\r
 120 also think it's a good idea to enable the possibility of frontend\r
 121 verification for frontends who want to do that (e.g. if i ever use a\r
 122 notmuch-based webmail app, i want my OpenPGP keyring stored on my local\r
 123 machine, not on the web server.  so i'd want my verification to happen\r
 124 on the locally-trusted hardware, too, not on the web server.\r
 125 \r
 126         --dkg\r
 127 \r
 128 \r
 129 --------------enigD73B070CC388B68353460BAC\r
 130 Content-Type: application/pgp-signature; name="signature.asc"\r
 131 Content-Description: OpenPGP digital signature\r
 132 Content-Disposition: attachment; filename="signature.asc"\r
 133 \r
 134 -----BEGIN PGP SIGNATURE-----\r
 135 Version: GnuPG v1.4.10 (GNU/Linux)\r
 136 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/\r
 137 \r
 138 iQIcBAEBCgAGBQJM4uRcAAoJEMzS7ZTSFznpExsP/3rBPdB/ExCz50ECwxoDSFuu\r
 139 ER7GEZX3H1ZrQMDg+jb0qodZCbN8Ov3awE6zGqfDI+L3ZbV8vCbud3kSFv19PcwK\r
 140 4LNLUW9RwhxtZWmse0WCZ85m7QrZi/g/pv4dc2YeFqmpuEvxIPp5zAkRGPgOumjp\r
 141 XgKvTf1FUfYu78oMGxWtZT0+sawEbVjXm2tp+5Resm42g7wi5SwL5vLhDsxHAUik\r
 142 stlAR+VrM8sKeHk8CyATVU6Tgcwr6CdLSBweNYhC05q6v0/g06QIib4GF3liaDXd\r
 143 IUYdT62HznL2VH9PqNLpcloFASEbDX5EFOBRGVDA6iI+JttdKPlmu+qqY9PI+WzC\r
 144 jMu19Q4U5cVN/qNGuqC3KBSGQd92tainBqMTYcE8W1nfX0d0IYl76xoLFmwQuOIZ\r
 145 gbjq7LKqjMfUtPqZZiRQT05dmbVdQWx46a/fkO15jWjbS5AZuWvEmlqj48dyE4Tz\r
 146 MxKGf3CSkDj0Ug6A5/B3A/u4/uPsCsAtLSEk6AAcOgeN3mI/NQLKpK2t1VFNhnbo\r
 147 8ZdTc+D4pYTxN2yO2Vcvb/tulpZlxteeF/hMDb4Gg15NJZhqr38U31f5nbMTC8zI\r
 148 3n2eJkxaLEM0oH72+PmKlPvdoR4pc2SXM/mVEcw66mTD6N3KjvXxOYlkLaianhQN\r
 149 MFWcvImF2mZX8MbLeYXH\r
 150 =qwDR\r
 151 -----END PGP SIGNATURE-----\r
 152 \r
 153 --------------enigD73B070CC388B68353460BAC--\r