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