new "crypto" branch providing full PGP/MIME support

[Daniel Kahn Gillmor]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110203/8c4b917c/attachment.pgp>