--- /dev/null
+Return-Path: <dkg@fifthhorseman.net>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id 644DF40DBC8\r
+ for <notmuch@notmuchmail.org>; Tue, 16 Nov 2010 12:07:13 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -1.899\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5\r
+ tests=[BAYES_00=-1.9, UNPARSEABLE_RELAY=0.001] autolearn=ham\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id QMGgvUSC215U for <notmuch@notmuchmail.org>;\r
+ Tue, 16 Nov 2010 12:07:02 -0800 (PST)\r
+Received: from rodolpho.mayfirst.org (mail.freitas.net [209.234.253.107])\r
+ (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))\r
+ (No client certificate requested)\r
+ by olra.theworths.org (Postfix) with ESMTPS id DC68F40DDCB\r
+ for <notmuch@notmuchmail.org>; Tue, 16 Nov 2010 12:07:01 -0800 (PST)\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by rodolpho.mayfirst.org (Postfix) with ESMTP id 5F1CB3CD51\r
+ for <notmuch@notmuchmail.org>; Tue, 16 Nov 2010 15:06:58 -0500 (EST)\r
+X-Virus-Scanned: Debian amavisd-new at rodolpho.mayfirst.org\r
+Received: from rodolpho.mayfirst.org ([127.0.0.1])\r
+ by localhost (rodolpho.mayfirst.org [127.0.0.1]) (amavisd-new,\r
+ port 10024) with ESMTP id mBgswJ46eZUX for <notmuch@notmuchmail.org>;\r
+ Tue, 16 Nov 2010 15:06:58 -0500 (EST)\r
+Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender:\r
+ smtpauth@rodolpho.mayfirst.org) with ESMTPSA id 17BFB3CD4C\r
+Message-ID: <4CE2E45C.7080206@fifthhorseman.net>\r
+Date: Tue, 16 Nov 2010 15:06:52 -0500\r
+From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>\r
+User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;\r
+ rv:1.9.2.9) Gecko/20100918 Icedove/3.1.4\r
+MIME-Version: 1.0\r
+To: notmuch <notmuch@notmuchmail.org>\r
+Subject: Re: a proposed change to JSON output to report verification of\r
+ PGP/MIME signatures.\r
+References: <4CDE4486.2050101@fifthhorseman.net>\r
+ <87hbfhdpa6.fsf@yoom.home.cworth.org>\r
+In-Reply-To: <87hbfhdpa6.fsf@yoom.home.cworth.org>\r
+X-Enigmail-Version: 1.1.2\r
+OpenPGP: id=D21739E9\r
+Content-Type: multipart/signed; micalg=pgp-sha512;\r
+ protocol="application/pgp-signature";\r
+ boundary="------------enigD73B070CC388B68353460BAC"\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+Reply-To: notmuch <notmuch@notmuchmail.org>\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Tue, 16 Nov 2010 20:07:13 -0000\r
+\r
+This is an OpenPGP/MIME signed message (RFC 2440 and 3156)\r
+--------------enigD73B070CC388B68353460BAC\r
+Content-Type: text/plain; charset=UTF-8\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+On 11/16/2010 02:47 PM, Carl Worth wrote:\r
+> The current linearization of parts is a bug that should be fixed. And I=\r
+\r
+> think several aspects of your proposal are effectively workarounds for\r
+> this bug. So I'd rather we fix the json output to emit the tree\r
+> structure first, and then see what parts of the proposal can be\r
+> eliminated.\r
+>=20\r
+> [And I think David Edmondson's reply said the same as above, but with\r
+> more detail. Right?]\r
+\r
+ok, good to know. that makes sense to me, and i'll plan my work around\r
+the idea of future tree-structured output. i didn't know whether the\r
+linearized output was considered a feature or not. tree-structured\r
+output makes me happier.\r
+\r
+> The only other piece I think I'd like to see is actually making the\r
+> content of the signature pieces available in the json output. Then, a\r
+> client could do its own verification.\r
+\r
+once we have tree-structured output, we'd only need to be able to\r
+request a literal byte-stream of any mime-part. so if the mime parts\r
+were structured this way:\r
+\r
+1=E2=94=94=E2=94=AC=E2=95=B4multipart/signed 80029 bytes\r
+2 =E2=94=9C=E2=94=AC=E2=95=B4multipart/mixed 78178 bytes\r
+3 =E2=94=82=E2=94=9C=E2=95=B4text/plain 699 bytes\r
+4 =E2=94=82=E2=94=94=E2=95=B4text/plain attachment [a_dancing_monkey.png]=\r
+ 76978 bytes\r
+5 =E2=94=94=E2=95=B4application/pgp-signature attachment [signature.asc] =\r
+892 bytes\r
+\r
+then the client would need to be able to extract a clean (untampered,\r
+internal-headers included) copy of part 2, to verify against the\r
+signature found in part 5.\r
+\r
+Note that "notmuch part" currently emits only the content of the emitted\r
+parts. it strips off the internal mime headers, and apparently does\r
+some form of content mangling too (base64 decoding, etc). this is\r
+unacceptable for the purposes of signature verification. Maybe notmuch\r
+part needs a --unfiltered flag or something?\r
+\r
+Note also that clients that are willing and able to parse mime\r
+structures themselves can already do the signature verification\r
+themselves by fetching the whole thing with --format=3Dmbox.\r
+\r
+> Then if we had that would we not want to add the --verify support into\r
+> notmuch? (My guess is that we still would want it.)\r
+\r
+i think it's a good idea to enable verification on the backend, because\r
+we don't want to force each frontend author to reinvent the wheel. I\r
+also think it's a good idea to enable the possibility of frontend\r
+verification for frontends who want to do that (e.g. if i ever use a\r
+notmuch-based webmail app, i want my OpenPGP keyring stored on my local\r
+machine, not on the web server. so i'd want my verification to happen\r
+on the locally-trusted hardware, too, not on the web server.\r
+\r
+ --dkg\r
+\r
+\r
+--------------enigD73B070CC388B68353460BAC\r
+Content-Type: application/pgp-signature; name="signature.asc"\r
+Content-Description: OpenPGP digital signature\r
+Content-Disposition: attachment; filename="signature.asc"\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1.4.10 (GNU/Linux)\r
+Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/\r
+\r
+iQIcBAEBCgAGBQJM4uRcAAoJEMzS7ZTSFznpExsP/3rBPdB/ExCz50ECwxoDSFuu\r
+ER7GEZX3H1ZrQMDg+jb0qodZCbN8Ov3awE6zGqfDI+L3ZbV8vCbud3kSFv19PcwK\r
+4LNLUW9RwhxtZWmse0WCZ85m7QrZi/g/pv4dc2YeFqmpuEvxIPp5zAkRGPgOumjp\r
+XgKvTf1FUfYu78oMGxWtZT0+sawEbVjXm2tp+5Resm42g7wi5SwL5vLhDsxHAUik\r
+stlAR+VrM8sKeHk8CyATVU6Tgcwr6CdLSBweNYhC05q6v0/g06QIib4GF3liaDXd\r
+IUYdT62HznL2VH9PqNLpcloFASEbDX5EFOBRGVDA6iI+JttdKPlmu+qqY9PI+WzC\r
+jMu19Q4U5cVN/qNGuqC3KBSGQd92tainBqMTYcE8W1nfX0d0IYl76xoLFmwQuOIZ\r
+gbjq7LKqjMfUtPqZZiRQT05dmbVdQWx46a/fkO15jWjbS5AZuWvEmlqj48dyE4Tz\r
+MxKGf3CSkDj0Ug6A5/B3A/u4/uPsCsAtLSEk6AAcOgeN3mI/NQLKpK2t1VFNhnbo\r
+8ZdTc+D4pYTxN2yO2Vcvb/tulpZlxteeF/hMDb4Gg15NJZhqr38U31f5nbMTC8zI\r
+3n2eJkxaLEM0oH72+PmKlPvdoR4pc2SXM/mVEcw66mTD6N3KjvXxOYlkLaianhQN\r
+MFWcvImF2mZX8MbLeYXH\r
+=qwDR\r
+-----END PGP SIGNATURE-----\r
+\r
+--------------enigD73B070CC388B68353460BAC--\r
projects / notmuch-archives.git / commitdiff