74/3897a5861fdaeb04d742cd71809fb3cd193391

   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 51CC2431FB6\r
   6         for <notmuch@notmuchmail.org>; Thu,  3 Feb 2011 11:52:09 -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: 0\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
  12         autolearn=disabled\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 BA4NHrARrtbO for <notmuch@notmuchmail.org>;\r
  16         Thu,  3 Feb 2011 11:52:08 -0800 (PST)\r
  17 Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108])\r
  18         by olra.theworths.org (Postfix) with ESMTP id 746A8431FB5\r
  19         for <notmuch@notmuchmail.org>; Thu,  3 Feb 2011 11:52:08 -0800 (PST)\r
  20 Received: from [192.168.13.75] (lair.fifthhorseman.net [216.254.116.241])\r
  21         by che.mayfirst.org (Postfix) with ESMTPSA id 0D664F98D\r
  22         for <notmuch@notmuchmail.org>; Thu,  3 Feb 2011 14:52:06 -0500 (EST)\r
  23 Message-ID: <4D4B0761.7040603@fifthhorseman.net>\r
  24 Date: Thu, 03 Feb 2011 14:52:01 -0500\r
  25 From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>\r
  26 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;\r
  27         rv:1.9.2.13) Gecko/20101213 Icedove/3.1.7\r
  28 MIME-Version: 1.0\r
  29 To: notmuch <notmuch@notmuchmail.org>\r
  30 Subject: Re: new "crypto" branch providing full PGP/MIME support\r
  31 References: <4CF15D67.1070904@fifthhorseman.net>\r
  32         <87aak08fu8.fsf@servo.finestructure.net>\r
  33         <87fwsf9mip.fsf@servo.finestructure.net>\r
  34         <87tygl29vu.fsf@servo.finestructure.net>        <87hbclkrvh.fsf@algae.riseup.net>\r
  35 In-Reply-To: <87hbclkrvh.fsf@algae.riseup.net>\r
  36 X-Enigmail-Version: 1.1.2\r
  37 Content-Type: multipart/signed; micalg=pgp-sha512;\r
  38         protocol="application/pgp-signature";\r
  39         boundary="------------enig287B05AD2BBADE2AE3F38430"\r
  40 X-BeenThere: notmuch@notmuchmail.org\r
  41 X-Mailman-Version: 2.1.13\r
  42 Precedence: list\r
  43 Reply-To: notmuch <notmuch@notmuchmail.org>\r
  44 List-Id: "Use and development of the notmuch mail system."\r
  45         <notmuch.notmuchmail.org>\r
  46 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  47         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  48 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  49 List-Post: <mailto:notmuch@notmuchmail.org>\r
  50 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  51 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  52         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  53 X-List-Received-Date: Thu, 03 Feb 2011 19:52:09 -0000\r
  54 \r
  55 This is an OpenPGP/MIME signed message (RFC 2440 and 3156)\r
  56 --------------enig287B05AD2BBADE2AE3F38430\r
  57 Content-Type: text/plain; charset=UTF-8\r
  58 Content-Transfer-Encoding: quoted-printable\r
  59 \r
  60 Hi Micah--\r
  61 \r
  62 just wanted to follow up on your points/questions:\r
  63 \r
  64 On 02/03/2011 11:25 AM, micah anderson wrote:\r
  65 > 1. I personally think notmuch-show-process-pgpmime should default to\r
  66 > true\r
  67 \r
  68 note that with it set to false, you can still M-RET (instead of RET) on\r
  69 an item in the summary window to have it set for that particular view.\r
  70 \r
  71 > 2. in-line pgp messages don't have any processing done on them. getting=\r
  72 \r
  73 > the mime-encoded processing work is a huge step and I'm happy that\r
  74 > works, in-line can (and IMHO, should) come later\r
  75 \r
  76 yeah, inline is a whole different thing, and much more difficult to\r
  77 manage programmatically in the notmuch backend, i think.  I dealing with\r
  78 inline signatures and encryption should be a job for the emacs (or vim\r
  79 or whatever) frontend.\r
  80 \r
  81 > 3. i'm not sure expired/revoked keys are handled properly - tested on a=\r
  82 \r
  83 > message that was encrypted by a key that was revoked and got "End of\r
  84 > file during parsing"\r
  85 \r
  86 when you say "encrypted by" do you mean "encrypted to"?  do you have\r
  87 access to the corresponding secret key?\r
  88 \r
  89 > 4. messages that I sent encrypted to someone are not also encrypted to\r
  90 > myself, which means that a thread which contains my replies isn't able\r
  91 > to decrypt my messages in that thread and results in a purple\r
  92 > 'decryption error'. Perhaps this is an emacs UI tweak that needs to be\r
  93 > made to get messages also encrypted to my own key?\r
  94 \r
  95 this is an issue for the emacs message modes (or maybe for your gpg\r
  96 configuration), not for notmuch.\r
  97 \r
  98 You either want to fix this in your emacs config by putting your\r
  99 fingerprint into mml2015-signers and setting mml2015-encrypt-to-self\r
 100 \r
 101 Or you want to set gpg's default-recipient-self option  (and\r
 102 default-recipient option if you hold more than one secret key and want\r
 103 to be sure it chooses the right one)\r
 104 \r
 105 > 5. unknown keys are represented in a long format,\r
 106 > eg. '0x5585F58CC827A062' when most tools represent them just with their=\r
 107 \r
 108 > shortened keyid (in this case this one would be: 0xC827A062), is there =\r
 109 a\r
 110 > particular reason for this?\r
 111 \r
 112 Short keyIDs are easily spoofable; believing anything based on a matched\r
 113 short keyID is a mistake.  "unknown keys" themselves may or may not have\r
 114 properly signed a message -- since we don't have the key handy, we don't\r
 115 have a way of checking.\r
 116 \r
 117 note that "unknown key" is different from "good signature from known key\r
 118 but we do not know who controls the key"\r
 119 \r
 120 > I recognize some people's keyids in the\r
 121 > short form, but do not in the longform.\r
 122 \r
 123 You can derive the short form from the long form by ignoring everything\r
 124 but the last 8 hex characters.  But if you actually recognize the short\r
 125 form, i'd expect you to have the relevant key in your keyring; is this\r
 126 really a use case worth bothering with?\r
 127 \r
 128 do you have a suggestion for how you think it should behave differently?\r
 129 \r
 130         --dkg\r
 131 \r
 132 \r
 133 --------------enig287B05AD2BBADE2AE3F38430\r
 134 Content-Type: application/pgp-signature; name="signature.asc"\r
 135 Content-Description: OpenPGP digital signature\r
 136 Content-Disposition: attachment; filename="signature.asc"\r
 137 \r
 138 -----BEGIN PGP SIGNATURE-----\r
 139 Version: GnuPG v1.4.11 (GNU/Linux)\r
 140 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/\r
 141 \r
 142 iQJ8BAEBCgBmBQJNSwdhXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w\r
 143 ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD\r
 144 Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznp3toQAKipDfqFteK9Zb9zfvEdWS5X\r
 145 lTUA5V78keOOELCRAE//TTbh1bSPIkRK8G1fK0JZuTarWkWzx5A6pGChvtzEZaMi\r
 146 +6TGE3C7hCunSgKkdhANM0jxC1nYZRyzrVk0/HBtupC7nnMT3kmfMVP56rbuXBZZ\r
 147 Cjvmi1MArtzPDyZeE92QvM9vrEQQHSduJMGlVuuvPF2lMgwuOiUpMxFsGrDQUGwM\r
 148 /mkt2Bu929N17fmTox+6jpFQCcjsAChryAQlZmwm1ShK+jLIo72QTAG+MXEWhqr4\r
 149 NtFvOYeg6j3jVT9cHJ9RgloTEPPTmz+N/zJ46EPpYqPFl/eEod8FtyCRFaJrUPsM\r
 150 2SL7apHjAxY6m+CmInRvVqqXeWf9zT2+XbyAtn+gi5i0sAzAdEfT0xkizo2DeSNN\r
 151 BT4t6JRjGFS3EBvwe1/nbGVnftrkVrBMu4ZY3gpdUkOpCtYE1osorzH2z2GgA2D+\r
 152 agdCtHEOWUvIJbIUpoMS0GvV3YmjBJuVDMvSsAKV/SFJEejtovEb5Ey2k7rYa1ki\r
 153 n4/IjZHfOhGM3sYQKKBFZyUlvDh1uQbd+iYmBIB7oH4v7XcTgj03ktXsJKOdlx/c\r
 154 Sj5ReFGLSkzs0VAMBV5AVK+1GKjeH8N6cNiqf5po2JjCZFYo5j0pDJ2c3a2t+KC3\r
 155 1XV+KpU62CkWK3sn4OFG\r
 156 =Vl2M\r
 157 -----END PGP SIGNATURE-----\r
 158 \r
 159 --------------enig287B05AD2BBADE2AE3F38430--\r