Re: new "crypto" branch providing full PGP/MIME support
authorDaniel Kahn Gillmor <dkg@fifthhorseman.net>
Thu, 3 Feb 2011 19:52:01 +0000 (14:52 +1900)
committerW. Trevor King <wking@tremily.us>
Fri, 7 Nov 2014 17:37:51 +0000 (09:37 -0800)
74/3897a5861fdaeb04d742cd71809fb3cd193391 [new file with mode: 0644]

diff --git a/74/3897a5861fdaeb04d742cd71809fb3cd193391 b/74/3897a5861fdaeb04d742cd71809fb3cd193391
new file mode 100644 (file)
index 0000000..4ede4a9
--- /dev/null
@@ -0,0 +1,159 @@
+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 51CC2431FB6\r
+       for <notmuch@notmuchmail.org>; Thu,  3 Feb 2011 11:52:09 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
+       autolearn=disabled\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 BA4NHrARrtbO for <notmuch@notmuchmail.org>;\r
+       Thu,  3 Feb 2011 11:52:08 -0800 (PST)\r
+Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108])\r
+       by olra.theworths.org (Postfix) with ESMTP id 746A8431FB5\r
+       for <notmuch@notmuchmail.org>; Thu,  3 Feb 2011 11:52:08 -0800 (PST)\r
+Received: from [192.168.13.75] (lair.fifthhorseman.net [216.254.116.241])\r
+       by che.mayfirst.org (Postfix) with ESMTPSA id 0D664F98D\r
+       for <notmuch@notmuchmail.org>; Thu,  3 Feb 2011 14:52:06 -0500 (EST)\r
+Message-ID: <4D4B0761.7040603@fifthhorseman.net>\r
+Date: Thu, 03 Feb 2011 14:52:01 -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.13) Gecko/20101213 Icedove/3.1.7\r
+MIME-Version: 1.0\r
+To: notmuch <notmuch@notmuchmail.org>\r
+Subject: Re: new "crypto" branch providing full PGP/MIME support\r
+References: <4CF15D67.1070904@fifthhorseman.net>\r
+       <87aak08fu8.fsf@servo.finestructure.net>\r
+       <87fwsf9mip.fsf@servo.finestructure.net>\r
+       <87tygl29vu.fsf@servo.finestructure.net>        <87hbclkrvh.fsf@algae.riseup.net>\r
+In-Reply-To: <87hbclkrvh.fsf@algae.riseup.net>\r
+X-Enigmail-Version: 1.1.2\r
+Content-Type: multipart/signed; micalg=pgp-sha512;\r
+       protocol="application/pgp-signature";\r
+       boundary="------------enig287B05AD2BBADE2AE3F38430"\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: Thu, 03 Feb 2011 19:52:09 -0000\r
+\r
+This is an OpenPGP/MIME signed message (RFC 2440 and 3156)\r
+--------------enig287B05AD2BBADE2AE3F38430\r
+Content-Type: text/plain; charset=UTF-8\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+Hi Micah--\r
+\r
+just wanted to follow up on your points/questions:\r
+\r
+On 02/03/2011 11:25 AM, micah anderson wrote:\r
+> 1. I personally think notmuch-show-process-pgpmime should default to\r
+> true\r
+\r
+note that with it set to false, you can still M-RET (instead of RET) on\r
+an item in the summary window to have it set for that particular view.\r
+\r
+> 2. in-line pgp messages don't have any processing done on them. getting=\r
+\r
+> the mime-encoded processing work is a huge step and I'm happy that\r
+> works, in-line can (and IMHO, should) come later\r
+\r
+yeah, inline is a whole different thing, and much more difficult to\r
+manage programmatically in the notmuch backend, i think.  I dealing with\r
+inline signatures and encryption should be a job for the emacs (or vim\r
+or whatever) frontend.\r
+\r
+> 3. i'm not sure expired/revoked keys are handled properly - tested on a=\r
+\r
+> message that was encrypted by a key that was revoked and got "End of\r
+> file during parsing"\r
+\r
+when you say "encrypted by" do you mean "encrypted to"?  do you have\r
+access to the corresponding secret key?\r
+\r
+> 4. messages that I sent encrypted to someone are not also encrypted to\r
+> myself, which means that a thread which contains my replies isn't able\r
+> to decrypt my messages in that thread and results in a purple\r
+> 'decryption error'. Perhaps this is an emacs UI tweak that needs to be\r
+> made to get messages also encrypted to my own key?\r
+\r
+this is an issue for the emacs message modes (or maybe for your gpg\r
+configuration), not for notmuch.\r
+\r
+You either want to fix this in your emacs config by putting your\r
+fingerprint into mml2015-signers and setting mml2015-encrypt-to-self\r
+\r
+Or you want to set gpg's default-recipient-self option  (and\r
+default-recipient option if you hold more than one secret key and want\r
+to be sure it chooses the right one)\r
+\r
+> 5. unknown keys are represented in a long format,\r
+> eg. '0x5585F58CC827A062' when most tools represent them just with their=\r
+\r
+> shortened keyid (in this case this one would be: 0xC827A062), is there =\r
+a\r
+> particular reason for this?\r
+\r
+Short keyIDs are easily spoofable; believing anything based on a matched\r
+short keyID is a mistake.  "unknown keys" themselves may or may not have\r
+properly signed a message -- since we don't have the key handy, we don't\r
+have a way of checking.\r
+\r
+note that "unknown key" is different from "good signature from known key\r
+but we do not know who controls the key"\r
+\r
+> I recognize some people's keyids in the\r
+> short form, but do not in the longform.\r
+\r
+You can derive the short form from the long form by ignoring everything\r
+but the last 8 hex characters.  But if you actually recognize the short\r
+form, i'd expect you to have the relevant key in your keyring; is this\r
+really a use case worth bothering with?\r
+\r
+do you have a suggestion for how you think it should behave differently?\r
+\r
+       --dkg\r
+\r
+\r
+--------------enig287B05AD2BBADE2AE3F38430\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.11 (GNU/Linux)\r
+Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/\r
+\r
+iQJ8BAEBCgBmBQJNSwdhXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w\r
+ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD\r
+Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznp3toQAKipDfqFteK9Zb9zfvEdWS5X\r
+lTUA5V78keOOELCRAE//TTbh1bSPIkRK8G1fK0JZuTarWkWzx5A6pGChvtzEZaMi\r
++6TGE3C7hCunSgKkdhANM0jxC1nYZRyzrVk0/HBtupC7nnMT3kmfMVP56rbuXBZZ\r
+Cjvmi1MArtzPDyZeE92QvM9vrEQQHSduJMGlVuuvPF2lMgwuOiUpMxFsGrDQUGwM\r
+/mkt2Bu929N17fmTox+6jpFQCcjsAChryAQlZmwm1ShK+jLIo72QTAG+MXEWhqr4\r
+NtFvOYeg6j3jVT9cHJ9RgloTEPPTmz+N/zJ46EPpYqPFl/eEod8FtyCRFaJrUPsM\r
+2SL7apHjAxY6m+CmInRvVqqXeWf9zT2+XbyAtn+gi5i0sAzAdEfT0xkizo2DeSNN\r
+BT4t6JRjGFS3EBvwe1/nbGVnftrkVrBMu4ZY3gpdUkOpCtYE1osorzH2z2GgA2D+\r
+agdCtHEOWUvIJbIUpoMS0GvV3YmjBJuVDMvSsAKV/SFJEejtovEb5Ey2k7rYa1ki\r
+n4/IjZHfOhGM3sYQKKBFZyUlvDh1uQbd+iYmBIB7oH4v7XcTgj03ktXsJKOdlx/c\r
+Sj5ReFGLSkzs0VAMBV5AVK+1GKjeH8N6cNiqf5po2JjCZFYo5j0pDJ2c3a2t+KC3\r
+1XV+KpU62CkWK3sn4OFG\r
+=Vl2M\r
+-----END PGP SIGNATURE-----\r
+\r
+--------------enig287B05AD2BBADE2AE3F38430--\r