normalizing part numbering across PGP/MIME processing

[Carl Worth]

On Sat, 28 May 2011 14:31:08 -0700, Jameson Graef Rollins  wrote:
> On Fri, 27 May 2011 17:53:44 -0700, Carl Worth  wrote:
> >   * Should we set the crypto option to verify/decrypt by default?
...
> I don't really have an opinion on this.  I have it set now, so whether
> or not it's set by default doesn't make much difference to me.

I'm inclined to set it by default. But I'll wait until I get it fully
working, (which looks to be problems in my environment). See below.

> >   * 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.

I'm still getting this. I'll start debugging libgmime next.

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

That part I at least figured out. This behavior can be replicated (for me) with:

LD_LIBRARY_PATH=/usr/lib gpg-agent

or:

LD_LIBRARY_PATH=/usr/lib:/lib gpg-agent

And it goes away with:

LD_LIBRARY_PATH=/lib:/usr/lib gpg-agent

It's still a mystifying bug in gpg-agent to me. But I've at least got my
environment to no longer trigger it, and I've opened a Debian bug report
for it at least.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

Re: normalizing part numbering across PGP/MIME processing

[Carl Worth]

On Sat, 28 May 2011 14:31:08 -0700, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 On Fri, 27 May 2011 17:53:44 -0700, Carl Worth cwo...@cworth.org wrote:
* Should we set the crypto option to verify/decrypt by default?
...
 I don't really have an opinion on this.  I have it set now, so whether
 or not it's set by default doesn't make much difference to me.

I'm inclined to set it by default. But I'll wait until I get it fully
working, (which looks to be problems in my environment). See below.

* 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.

I'm still getting this. I'll start debugging libgmime next.

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

That part I at least figured out. This behavior can be replicated (for me) with:

LD_LIBRARY_PATH=/usr/lib gpg-agent

or:

LD_LIBRARY_PATH=/usr/lib:/lib gpg-agent

And it goes away with:

LD_LIBRARY_PATH=/lib:/usr/lib gpg-agent

It's still a mystifying bug in gpg-agent to me. But I've at least got my
environment to no longer trigger it, and I've opened a Debian bug report
for it at least.

-Carl


pgpJYUZppOY4g.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

normalizing part numbering across PGP/MIME processing

[Jameson Graef Rollins]

On Fri, 27 May 2011 17:53:44 -0700, Carl Worth  wrote:
> 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).

w00t!  Thanks so much, Carl!  I definitely think the whole branch turned
out to be a lot cleaner in the end.

> 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.

Yes, I agree.  I'm about to send a patch series to the list that
includes a bunch of random stuff that should be include in 0.6, and it
includes some of these fixes.

>   * 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 don't really have an opinion on this.  I have it set now, so whether
or not it's set by default doesn't make much difference to me.

>   * 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 agree it would definitely be better to have the redisplay happen from
inside the message show.  That would be much cleaner and more intuitive.
It will require a bit of work to add something like a "redisplay" in
notmuch-show, but I see no reason it can't be done.

>   * 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.

Yikes!

>   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.

hrm, that's very strange, unfortunately I'm not sure what's happening
there.  Bug in gpg-agent, I assume?

>   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?

That's a good question, actually, and I don't actually know the answer.

Ok, so more release-candidate/0.6 patches to follow.

Thanks again for pushing all this stuff through, Carl.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: normalizing part numbering across PGP/MIME processing

[Jameson Graef Rollins]

On Fri, 27 May 2011 17:53:44 -0700, Carl Worth cwo...@cworth.org wrote:
 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).

w00t!  Thanks so much, Carl!  I definitely think the whole branch turned
out to be a lot cleaner in the end.

 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.

Yes, I agree.  I'm about to send a patch series to the list that
includes a bunch of random stuff that should be include in 0.6, and it
includes some of these fixes.

   * 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 don't really have an opinion on this.  I have it set now, so whether
or not it's set by default doesn't make much difference to me.

   * 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 agree it would definitely be better to have the redisplay happen from
inside the message show.  That would be much cleaner and more intuitive.
It will require a bit of work to add something like a redisplay in
notmuch-show, but I see no reason it can't be done.

   * 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.

Yikes!

   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.

hrm, that's very strange, unfortunately I'm not sure what's happening
there.  Bug in gpg-agent, I assume?

   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?

That's a good question, actually, and I don't actually know the answer.

Ok, so more release-candidate/0.6 patches to follow.

Thanks again for pushing all this stuff through, Carl.

jamie.


pgpGa5r7sPfV8.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

normalizing part numbering across PGP/MIME processing

[Carl Worth]

On Fri, 27 May 2011 03:27:35 -0700, Jameson Graef Rollins  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: 

normalizing part numbering across PGP/MIME processing

[Daniel Kahn Gillmor]

On Fri, 27 May 2011 03:27:35 -0700, Jameson Graef Rollins  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.  We'll have to live with the encrypted multipart
> renumbering until we have a more sophisticated part numbering scheme.
> However, that's a separate issue that can hopefully be dealt with
> after the full crypto functionality is pulled.

These patches resolve my outstanding part-numbering concern with the
crypto verification business.  I recommend merging them to the mainline.

Then can we release 0.6 pretty please? :)

There's nothing stopping us from releasing 0.7 if there are more
features pending, but i'd really like to be able to say "please run 0.6
or later to handle verifying cryptographic signatures".

 --dkg
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 965 bytes
Desc: not available
URL: 

normalizing part numbering across PGP/MIME processing

[Jameson Graef Rollins]

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.  We'll have to live with the encrypted multipart
renumbering until we have a more sophisticated part numbering scheme.
However, that's a separate issue that can hopefully be dealt with
after the full crypto functionality is pulled.

jamie.

normalizing part numbering across PGP/MIME processing

[Jameson Graef Rollins]

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.  We'll have to live with the encrypted multipart
renumbering until we have a more sophisticated part numbering scheme.
However, that's a separate issue that can hopefully be dealt with
after the full crypto functionality is pulled.

jamie.

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: normalizing part numbering across PGP/MIME processing

[Daniel Kahn Gillmor]

On Fri, 27 May 2011 03:27:35 -0700, Jameson Graef Rollins 
jroll...@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.  We'll have to live with the encrypted multipart
 renumbering until we have a more sophisticated part numbering scheme.
 However, that's a separate issue that can hopefully be dealt with
 after the full crypto functionality is pulled.

These patches resolve my outstanding part-numbering concern with the
crypto verification business.  I recommend merging them to the mainline.

Then can we release 0.6 pretty please? :)

There's nothing stopping us from releasing 0.7 if there are more
features pending, but i'd really like to be able to say please run 0.6
or later to handle verifying cryptographic signatures.

 --dkg


pgpImUy7Xwk18.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: normalizing part numbering across PGP/MIME processing

[Carl Worth]

On Fri, 27 May 2011 03:27:35 -0700, Jameson Graef Rollins 
jroll...@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.wo...@intel.com


pgpV0zSaGyo3c.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch