normalizing part numbering across PGP/MIME processing

[Carl Worth]

On Fri, 27 May 2011 03:27:35 -0700, Jameson Graef Rollins <jrollins at finestructure.net> wrote:
> Ok.  So I very much hope this patch series satisfies those who were
> bothered by the part renumbering that was happening when PGP/MIME
> parts were processed.  For signed messages we no longer modify the
> parts at all, so numbering always remains constant, and for encrypted
> messages the numbering will only change if the encrypted message is
> itself multipart.

That sounds much better to me. I think the remaining issues I have with
the patch series are very minor and can be applied after the fact. I'd
push the series right now except that I happen to have no network access
at the moment. [I'm queueing up this message for delivery, so if I'm on
top of things when I'm back in range, I'll push right away.]

So, well done, Jameson! You've been extremely patient as I sat on this
patch series for *so* long, and then made you rebuild it so many
times. I hope you think the rebuilds were at least worth it for the much
cleaner final state, (I know that the useless waiting wasn't worth it).

I promise you don't need to rebuild this branch anymore, nor keep asking
me to merge it. Go enjoy a good US-holiday weekend. You've earned it!

That said, here are the (minor) issues I have with the series:

  * More tests should be switched to the new text_expect_equal_file

	This isn't a problem with the series---but will be a nice
	fix. I think the current "notmuch search --output=tags *" is
	broken due to a missing final newline---or at least has been
	broken that way recently. So it will be nice to have this
	support for testing a final newline.

  * The series duplicates some existing code into a new
    emacs_deliver_message

	The previously-existing code should be removed and replaced with
	a call to the new function.

  * Should we set the crypto option to verify/decrypt by default?

	That would certainly be convenient for me at least.

	For people who don't want this, they can set the variable to
	nil. But then they'll still have the following issue:

  * I'm not a fan of the M-RET option for decrypting a message

	If someone is going to have encrypted messages not decrypted by
	default, then they can currently decrypt by opening the message
	with M-RET. But I think in common use, the user is likely to
	only realize too late that they want to decrypt the message.

	So what I'd love to see is a keybinding for decrypting a message
	from the view of the message itself. (One natural place would be
	by activating the button of the encrypted part---but a
	keybinding to review with decryption would be fine too---likely
	easier to code and easier to use.)

  * I can't actually get decryption to work for me. :-(

	When I run "notmuch show --decrypt" on a message encrypted with
	my public key I get a segfault within libgmime, specifically in
	the g_mime_session_request_passwd function.

	My first guess is that this is due to the fact that gpg-agent
	can't be run on my system (Debian unstable):

	$ gpg-agent
	gpg-agent: symbol lookup error: /usr/lib/libassuan.so.0: undefined symbol: gpg_err_set_errno

	I've got a Debian bug report queued up for this.

	I also tried running the same "notmuch show" command without
	gpg-agent installed. How is libgmime supposed to actually
	request a password in a case like this?

	Anyway, I know that not everyone has this same problem with the
	series, so I'm not blocking it for this.

-Carl

-- 
carl.d.worth at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110527/23ad4e6a/attachment.pgp>