[PATCH] Add pseudo-compatibility with gmime 2.6

[Tomi Ollila]

On Fri, 20 Jan 2012 00:52:47 +0100, Thomas Jost  
wrote:
> 
> Here is how I did:
> 
>   (ldd notmuch | grep -q gmime-2.6) && test_subtest_known_broken
> 
> ldd notmuch will show "/path/to/libgmime-2.4.so.*" or
> "libgmime-2.6.so.*" so we can easily check this in the test suite.
> It's a little hacky but it seems to work. AFAIK ldd is a pretty standard
> tool so it should be available (almost) everywhere. However if you have
> a better idea I'll be glad to hear it.

The "hack" is good in a sense that if that check fails in any case
the test_subtest_known_broken is not executed and we get FAIL instead of
BROKEN.
The subshell is unneeded:

ldd notmuch | grep -q gmime-2.6 && test_subtest_known_broken

does the trick (potentially less forks)... ok now I have to test ;)

haha:
 $ rm xfoo.* xbar.*

 $ strace -ff -o xfoo sh -c '(ldd /bin/ls | grep -q libc) && echo foo'
 foo
 $ ls xfoo.*
 xfoo.14277  xfoo.14279  xfoo.14281  xfoo.14283  xfoo.14285
 xfoo.14278  xfoo.14280  xfoo.14282  xfoo.14284

 $ strace -ff -o xbar sh -c 'ldd /bin/ls | grep -q libc && echo foo'
 foo
 $ ls xbar.*
 xbar.14292  xbar.14294  xbar.14296  xbar.14298
 xbar.14293  xbar.14295  xbar.14297  xbar.14299


Tomi

[PATCH] Add pseudo-compatibility with gmime 2.6

[Thomas Jost]

On Tue, 17 Jan 2012 15:38:36 -0500, Austin Clements  wrote:
> Quoth Thomas Jost on Jan 17 at 11:48 am:
> > On Mon, 16 Jan 2012 22:47:14 -0500, Austin Clements  
> > wrote:
> > > Quoth Thomas Jost on Jan 17 at 12:56 am:
> > > > This is mostly based on id:"8762i8hrb9.fsf at bookbinder.fernseed.info".
> > > > 
> > > > This was tested against both gmime 2.6.4 and 2.4.31. With gmime 2.4.31, 
> > > > the
> > > > crypto tests all work fine (as expected). With gmime 2.6.4, one crypto 
> > > > test
> > > > fails (signature verification with signer key unavailable) but this 
> > > > will be hard
> > > > to fix since the new API does not report the reason why a signature 
> > > > verification
> > > > fails (other than the human-readable error message).
> > > 
> > > What is the result of this failing test?
> > 
> > The test looks like that:
> > 
> > FAIL   signature verification with signer key unavailable
> >--- crypto.4.expected   2012-01-16 23:05:06.765651183 +
> >+++ crypto.4.output 2012-01-16 23:05:06.765651183 +
> >@@ -12,9 +12,7 @@
> >  "Bcc": "",
> >  "Date": "01 Jan 2000 12:00:00 -"},
> >  "body": [{"id": 1,
> >- "sigstatus": [{"status": "error",
> >- "keyid": "6D92612D94E46381",
> >- "errors": 2}],
> >+ "sigstatus": [],
> >  "content-type": "multipart/signed",
> >  "content": [{"id": 2,
> >  "content-type": "text/plain",
> >Failed to verify signed part: gpg: keyblock resource 
> > `/home/schnouki/dev/notmuch/test/tmp.crypto/gnupg/pubring.gpg': file open 
> > error
> >gpg: armor header: Version: GnuPG v1.4.11 (GNU/Linux)
> >gpg: Signature made Mon Jan 16 23:05:06 2012 UTC using RSA key ID 
> > 94E46381
> >gpg: Can't check signature: public key not found
> > 
> > So basically if a signer public key is missing, we can't get the status
> > signature: empty "sigstatus" field in the JSON output, "Unknown
> > signature status" in Emacs.
> > 
> > IMHO this is a bug in gmime 2.6, and I think I know what causes it. I'll
> > file a bug in gmime and hopefully they'll find a cleaner way to fix it
> > than the one I came up with :)
> 
> Oh, okay.  That does seem like a bug in GMime.  Do you think it would
> be possible to mark this test as "broken" if notmuch is using GMime
> 2.6?  Off the top of my head, I can't think of an easy way to plumb
> that information through to the test suite.  I don't think we should
> push any patches that knowingly break a test, even if it's in just one
> configuration.

Here is how I did:

  (ldd notmuch | grep -q gmime-2.6) && test_subtest_known_broken

ldd notmuch will show "/path/to/libgmime-2.4.so.*" or
"libgmime-2.6.so.*" so we can easily check this in the test suite.
It's a little hacky but it seems to work. AFAIK ldd is a pretty standard
tool so it should be available (almost) everywhere. However if you have
a better idea I'll be glad to hear it.

> > > > +#ifdef GMIME_26
> > > > +if (node->verify_attempted && !node->sig_list)
> > > 
> > > Hmm.  This is correct for signed parts, but will incorrectly trigger
> > > for an encrypted part with no signatures.  For 2.6, I think this error
> > > checking may have to move into the branches of the if encrypted/signed
> > > since for encrypted parts you have to check if
> > > g_mime_multipart_encrypted_decrypt returned NULL.
> > 
> > That sound right. The weird part is that it did not cause anything to
> > fail in the test suite...
> 
> It would be worth adding a test with an encrypted but unsigned part.
> I don't know enough GPG myself to do that.

It looks like there's already one: "emacs delivery of encrypted message
with attachment" + following decryptions.

Regards,

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

Re: [PATCH] Add pseudo-compatibility with gmime 2.6

[Tomi Ollila]

On Fri, 20 Jan 2012 00:52:47 +0100, Thomas Jost schno...@schnouki.net wrote:
 
 Here is how I did:
 
   (ldd notmuch | grep -q gmime-2.6)  test_subtest_known_broken
 
 ldd notmuch will show /path/to/libgmime-2.4.so.* or
 libgmime-2.6.so.* so we can easily check this in the test suite.
 It's a little hacky but it seems to work. AFAIK ldd is a pretty standard
 tool so it should be available (almost) everywhere. However if you have
 a better idea I'll be glad to hear it.

The hack is good in a sense that if that check fails in any case
the test_subtest_known_broken is not executed and we get FAIL instead of
BROKEN.
The subshell is unneeded:

ldd notmuch | grep -q gmime-2.6  test_subtest_known_broken

does the trick (potentially less forks)... ok now I have to test ;)

haha:
 $ rm xfoo.* xbar.*
 
 $ strace -ff -o xfoo sh -c '(ldd /bin/ls | grep -q libc)  echo foo'
 foo
 $ ls xfoo.*
 xfoo.14277  xfoo.14279  xfoo.14281  xfoo.14283  xfoo.14285
 xfoo.14278  xfoo.14280  xfoo.14282  xfoo.14284

 $ strace -ff -o xbar sh -c 'ldd /bin/ls | grep -q libc  echo foo'
 foo
 $ ls xbar.*
 xbar.14292  xbar.14294  xbar.14296  xbar.14298
 xbar.14293  xbar.14295  xbar.14297  xbar.14299


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

Re: [PATCH] Add pseudo-compatibility with gmime 2.6

[Thomas Jost]

On Tue, 17 Jan 2012 15:38:36 -0500, Austin Clements amdra...@mit.edu wrote:
 Quoth Thomas Jost on Jan 17 at 11:48 am:
  On Mon, 16 Jan 2012 22:47:14 -0500, Austin Clements amdra...@mit.edu 
  wrote:
   Quoth Thomas Jost on Jan 17 at 12:56 am:
This is mostly based on id:8762i8hrb9@bookbinder.fernseed.info.

This was tested against both gmime 2.6.4 and 2.4.31. With gmime 2.4.31, 
the
crypto tests all work fine (as expected). With gmime 2.6.4, one crypto 
test
fails (signature verification with signer key unavailable) but this 
will be hard
to fix since the new API does not report the reason why a signature 
verification
fails (other than the human-readable error message).
   
   What is the result of this failing test?
  
  The test looks like that:
  
  FAIL   signature verification with signer key unavailable
 --- crypto.4.expected   2012-01-16 23:05:06.765651183 +
 +++ crypto.4.output 2012-01-16 23:05:06.765651183 +
 @@ -12,9 +12,7 @@
   Bcc: ,
   Date: 01 Jan 2000 12:00:00 -},
   body: [{id: 1,
 - sigstatus: [{status: error,
 - keyid: 6D92612D94E46381,
 - errors: 2}],
 + sigstatus: [],
   content-type: multipart/signed,
   content: [{id: 2,
   content-type: text/plain,
 Failed to verify signed part: gpg: keyblock resource 
  `/home/schnouki/dev/notmuch/test/tmp.crypto/gnupg/pubring.gpg': file open 
  error
 gpg: armor header: Version: GnuPG v1.4.11 (GNU/Linux)
 gpg: Signature made Mon Jan 16 23:05:06 2012 UTC using RSA key ID 
  94E46381
 gpg: Can't check signature: public key not found
  
  So basically if a signer public key is missing, we can't get the status
  signature: empty sigstatus field in the JSON output, Unknown
  signature status in Emacs.
  
  IMHO this is a bug in gmime 2.6, and I think I know what causes it. I'll
  file a bug in gmime and hopefully they'll find a cleaner way to fix it
  than the one I came up with :)
 
 Oh, okay.  That does seem like a bug in GMime.  Do you think it would
 be possible to mark this test as broken if notmuch is using GMime
 2.6?  Off the top of my head, I can't think of an easy way to plumb
 that information through to the test suite.  I don't think we should
 push any patches that knowingly break a test, even if it's in just one
 configuration.

Here is how I did:

  (ldd notmuch | grep -q gmime-2.6)  test_subtest_known_broken

ldd notmuch will show /path/to/libgmime-2.4.so.* or
libgmime-2.6.so.* so we can easily check this in the test suite.
It's a little hacky but it seems to work. AFAIK ldd is a pretty standard
tool so it should be available (almost) everywhere. However if you have
a better idea I'll be glad to hear it.

+#ifdef GMIME_26
+if (node-verify_attempted  !node-sig_list)
   
   Hmm.  This is correct for signed parts, but will incorrectly trigger
   for an encrypted part with no signatures.  For 2.6, I think this error
   checking may have to move into the branches of the if encrypted/signed
   since for encrypted parts you have to check if
   g_mime_multipart_encrypted_decrypt returned NULL.
  
  That sound right. The weird part is that it did not cause anything to
  fail in the test suite...
 
 It would be worth adding a test with an encrypted but unsigned part.
 I don't know enough GPG myself to do that.

It looks like there's already one: emacs delivery of encrypted message
with attachment + following decryptions.

Regards,

-- 
Thomas/Schnouki


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

[PATCH] Add pseudo-compatibility with gmime 2.6

[Austin Clements]

Quoth Thomas Jost on Jan 17 at 11:48 am:
> On Mon, 16 Jan 2012 22:47:14 -0500, Austin Clements  
> wrote:
> > Quoth Thomas Jost on Jan 17 at 12:56 am:
> > > This is mostly based on id:"8762i8hrb9.fsf at bookbinder.fernseed.info".
> > > 
> > > This was tested against both gmime 2.6.4 and 2.4.31. With gmime 2.4.31, 
> > > the
> > > crypto tests all work fine (as expected). With gmime 2.6.4, one crypto 
> > > test
> > > fails (signature verification with signer key unavailable) but this will 
> > > be hard
> > > to fix since the new API does not report the reason why a signature 
> > > verification
> > > fails (other than the human-readable error message).
> > 
> > What is the result of this failing test?
> 
> The test looks like that:
> 
> FAIL   signature verification with signer key unavailable
>--- crypto.4.expected   2012-01-16 23:05:06.765651183 +
>+++ crypto.4.output 2012-01-16 23:05:06.765651183 +
>@@ -12,9 +12,7 @@
>  "Bcc": "",
>  "Date": "01 Jan 2000 12:00:00 -"},
>  "body": [{"id": 1,
>- "sigstatus": [{"status": "error",
>- "keyid": "6D92612D94E46381",
>- "errors": 2}],
>+ "sigstatus": [],
>  "content-type": "multipart/signed",
>  "content": [{"id": 2,
>  "content-type": "text/plain",
>Failed to verify signed part: gpg: keyblock resource 
> `/home/schnouki/dev/notmuch/test/tmp.crypto/gnupg/pubring.gpg': file open 
> error
>gpg: armor header: Version: GnuPG v1.4.11 (GNU/Linux)
>gpg: Signature made Mon Jan 16 23:05:06 2012 UTC using RSA key ID 
> 94E46381
>gpg: Can't check signature: public key not found
> 
> So basically if a signer public key is missing, we can't get the status
> signature: empty "sigstatus" field in the JSON output, "Unknown
> signature status" in Emacs.
> 
> IMHO this is a bug in gmime 2.6, and I think I know what causes it. I'll
> file a bug in gmime and hopefully they'll find a cleaner way to fix it
> than the one I came up with :)

Oh, okay.  That does seem like a bug in GMime.  Do you think it would
be possible to mark this test as "broken" if notmuch is using GMime
2.6?  Off the top of my head, I can't think of an easy way to plumb
that information through to the test suite.  I don't think we should
push any patches that knowingly break a test, even if it's in just one
configuration.

> > 
> > > ---
> > >  mime-node.c  |   50 ++-
> > >  notmuch-client.h |   27 ++-
> > >  notmuch-reply.c  |7 
> > >  notmuch-show.c   |   97 
> > > ++
> > >  show-message.c   |4 ++
> > >  5 files changed, 181 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/mime-node.c b/mime-node.c
> > > index d26bb44..ae2473d 100644
> > > --- a/mime-node.c
> > > +++ b/mime-node.c
> > > @@ -33,7 +33,11 @@ typedef struct mime_node_context {
> > >  GMimeMessage *mime_message;
> > >  
> > >  /* Context provided by the caller. */
> > > +#ifdef GMIME_26
> > > +GMimeCryptoContext *cryptoctx;
> > > +#else
> > >  GMimeCipherContext *cryptoctx;
> > > +#endif
> > >  notmuch_bool_t decrypt;
> > >  } mime_node_context_t;
> > >  
> > > @@ -57,8 +61,12 @@ _mime_node_context_free (mime_node_context_t *res)
> > >  
> > >  notmuch_status_t
> > >  mime_node_open (const void *ctx, notmuch_message_t *message,
> > > - GMimeCipherContext *cryptoctx, notmuch_bool_t decrypt,
> > > - mime_node_t **root_out)
> > > +#ifdef GMIME_26
> > > + GMimeCryptoContext *cryptoctx,
> > > +#else
> > > + GMimeCipherContext *cryptoctx,
> > > +#endif
> > > + notmuch_bool_t decrypt, mime_node_t **root_out)
> > >  {
> > >  const char *filename = notmuch_message_get_filename (message);
> > >  mime_node_context_t *mctx;
> > > @@ -112,12 +120,21 @@ DONE:
> > >  return status;
> > >  }
> > >  
> > > +#ifdef GMIME_26
> > > +static int
> > > +_signature_list_free (GMimeSignatureList **proxy)
> > > +{
> > > +g_object_unref (*proxy);
> > > +return 0;
> > > +}
> > > +#else
> > >  static int
> > >  _signature_validity_free (GMimeSignatureValidity **proxy)
> > >  {
> > >  g_mime_signature_validity_free (*proxy);
> > >  return 0;
> > >  }
> > > +#endif
> > >  
> > >  static mime_node_t *
> > >  _mime_node_create (const mime_node_t *parent, GMimeObject *part)
> > > @@ -165,11 +182,23 @@ _mime_node_create (const mime_node_t *parent, 
> > > GMimeObject *part)
> > >   GMimeMultipartEncrypted *encrypteddata =
> > >   GMIME_MULTIPART_ENCRYPTED (part);
> > >   node->decrypt_attempted = TRUE;
> > > +#ifdef GMIME_26
> > > + GMimeDecryptResult *decrypt_result = g_mime_decrypt_result_new ();
> > 
> > I think g_mime_multipart_encrypted_decrypt allocates the
> > GMimeDecryptResult for you, so this will just leak memory.
> 
> You're right, fixed. Will it 

[PATCH] Add pseudo-compatibility with gmime 2.6

[Adrian Perez]

Hi, 

Just a couple of comments inline :)

On Mon, 16 Jan 2012 22:47:14 -0500, Austin Clements  wrote:
> Quoth Thomas Jost on Jan 17 at 12:56 am:
> > There are lots of API changes in gmime 2.6 crypto handling. By adding
> > preprocessor directives, it is however possible to add gmime 2.6 
> > compatibility
> > while preserving compatibility with gmime 2.4 too.
> 
> Awesome.  Comments inline below.
> 
> > This is mostly based on id:"8762i8hrb9.fsf at bookbinder.fernseed.info".
> > 
> > This was tested against both gmime 2.6.4 and 2.4.31. With gmime 2.4.31, the
> > crypto tests all work fine (as expected). With gmime 2.6.4, one crypto test
> > fails (signature verification with signer key unavailable) but this will be 
> > hard
> > to fix since the new API does not report the reason why a signature 
> > verification
> > fails (other than the human-readable error message).
> 
> What is the result of this failing test?
> 
> > ---
> >  mime-node.c  |   50 ++-
> >  notmuch-client.h |   27 ++-
> >  notmuch-reply.c  |7 
> >  notmuch-show.c   |   97 
> > ++
> >  show-message.c   |4 ++
> >  5 files changed, 181 insertions(+), 4 deletions(-)
> > 
> > diff --git a/mime-node.c b/mime-node.c
> > index d26bb44..ae2473d 100644
> > --- a/mime-node.c
> > +++ b/mime-node.c
> > @@ -33,7 +33,11 @@ typedef struct mime_node_context {
> >  GMimeMessage *mime_message;
> >  
> >  /* Context provided by the caller. */
> > +#ifdef GMIME_26
> > +GMimeCryptoContext *cryptoctx;
> > +#else
> >  GMimeCipherContext *cryptoctx;
> > +#endif
> >  notmuch_bool_t decrypt;
> >  } mime_node_context_t;
> >  
> > @@ -57,8 +61,12 @@ _mime_node_context_free (mime_node_context_t *res)
> >  
> >  notmuch_status_t
> >  mime_node_open (const void *ctx, notmuch_message_t *message,
> > -   GMimeCipherContext *cryptoctx, notmuch_bool_t decrypt,
> > -   mime_node_t **root_out)
> > +#ifdef GMIME_26
> > +   GMimeCryptoContext *cryptoctx,
> > +#else
> > +   GMimeCipherContext *cryptoctx,
> > +#endif
> > +   notmuch_bool_t decrypt, mime_node_t **root_out)
> >  {
> >  const char *filename = notmuch_message_get_filename (message);
> >  mime_node_context_t *mctx;
> > @@ -112,12 +120,21 @@ DONE:
> >  return status;
> >  }
> >  
> > +#ifdef GMIME_26
> > +static int
> > +_signature_list_free (GMimeSignatureList **proxy)
> > +{
> > +g_object_unref (*proxy);
> > +return 0;
> > +}
> > +#else
> >  static int
> >  _signature_validity_free (GMimeSignatureValidity **proxy)
> >  {
> >  g_mime_signature_validity_free (*proxy);
> >  return 0;
> >  }
> > +#endif
> >  
> >  static mime_node_t *
> >  _mime_node_create (const mime_node_t *parent, GMimeObject *part)
> > @@ -165,11 +182,23 @@ _mime_node_create (const mime_node_t *parent, 
> > GMimeObject *part)
> > GMimeMultipartEncrypted *encrypteddata =
> > GMIME_MULTIPART_ENCRYPTED (part);
> > node->decrypt_attempted = TRUE;
> > +#ifdef GMIME_26
> > +   GMimeDecryptResult *decrypt_result = g_mime_decrypt_result_new ();
> 
> I think g_mime_multipart_encrypted_decrypt allocates the
> GMimeDecryptResult for you, so this will just leak memory.

Yes, this is a leak. The documentation says that the function is
responsible of allocating the GMimeDecryptResult. The g_object_unref()
is still needed in notmuch's code to free it, though.

See 
http://git.gnome.org/browse/gmime/tree/gmime/gmime-multipart-encrypted.c#n282

> > +   node->decrypted_child = g_mime_multipart_encrypted_decrypt
> > +   (encrypteddata, node->ctx->cryptoctx, _result, );
> > +   if (node->decrypted_child) {
> > +   node->decrypt_success = node->verify_attempted = TRUE;
> > +   node->sig_list = g_mime_decrypt_result_get_signatures 
> > (decrypt_result);
> > +   if (!node->sig_list)
> > +   fprintf (stderr, "Failed to get signatures: %s\n",
> > +(err ? err->message : "no error explanation 
> > given"));
> 
> My understanding is that g_mime_decrypt_result_get_signatures returns
> NULL if there are no signatures and that this isn't an error.  This
> differs from 2.4, which would return an empty but non-NULL list.
> 
> Also, I believe you have to free the sig_list in both branches now,
> which means the talloc_set_destructor can be moved to common logic
> outside of the if decrypted/signed.
> 
> > +#else
> > node->decrypted_child = g_mime_multipart_encrypted_decrypt
> > (encrypteddata, node->ctx->cryptoctx, );
> > if (node->decrypted_child) {
> > node->decrypt_success = node->verify_attempted = TRUE;
> > node->sig_validity = 
> > g_mime_multipart_encrypted_get_signature_validity (encrypteddata);
> > +#endif
> 
> It's confusing to have the open braces in the #ifdef'd region with a
> matching close brace outside of it (and I 

[PATCH] Add pseudo-compatibility with gmime 2.6

[Adrian Perez]

Hi,

On Tue, 17 Jan 2012 00:56:39 +0100, Thomas Jost  
wrote:

> There are lots of API changes in gmime 2.6 crypto handling. By adding
> preprocessor directives, it is however possible to add gmime 2.6 compatibility
> while preserving compatibility with gmime 2.4 too.

This approach is better than just dropping support for 2.4 (as my patch
does), so I would favor integrating this one instead of mine :D

Br.

-- 
Adrian Perez  - Sent from my toaster
Igalia - Free Software Engineering
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

[PATCH] Add pseudo-compatibility with gmime 2.6

[Thomas Jost]

On Mon, 16 Jan 2012 22:47:14 -0500, Austin Clements  wrote:
> Quoth Thomas Jost on Jan 17 at 12:56 am:
> > There are lots of API changes in gmime 2.6 crypto handling. By adding
> > preprocessor directives, it is however possible to add gmime 2.6 
> > compatibility
> > while preserving compatibility with gmime 2.4 too.
> 
> Awesome.  Comments inline below.

Thanks for reviewing this so quickly. Replies inline, and new patches
incoming soon.


> > This is mostly based on id:"8762i8hrb9.fsf at bookbinder.fernseed.info".
> > 
> > This was tested against both gmime 2.6.4 and 2.4.31. With gmime 2.4.31, the
> > crypto tests all work fine (as expected). With gmime 2.6.4, one crypto test
> > fails (signature verification with signer key unavailable) but this will be 
> > hard
> > to fix since the new API does not report the reason why a signature 
> > verification
> > fails (other than the human-readable error message).
> 
> What is the result of this failing test?

The test looks like that:

FAIL   signature verification with signer key unavailable
   --- crypto.4.expected   2012-01-16 23:05:06.765651183 +
   +++ crypto.4.output 2012-01-16 23:05:06.765651183 +
   @@ -12,9 +12,7 @@
 "Bcc": "",
 "Date": "01 Jan 2000 12:00:00 -"},
 "body": [{"id": 1,
   - "sigstatus": [{"status": "error",
   - "keyid": "6D92612D94E46381",
   - "errors": 2}],
   + "sigstatus": [],
 "content-type": "multipart/signed",
 "content": [{"id": 2,
 "content-type": "text/plain",
   Failed to verify signed part: gpg: keyblock resource 
`/home/schnouki/dev/notmuch/test/tmp.crypto/gnupg/pubring.gpg': file open error
   gpg: armor header: Version: GnuPG v1.4.11 (GNU/Linux)
   gpg: Signature made Mon Jan 16 23:05:06 2012 UTC using RSA key ID 
94E46381
   gpg: Can't check signature: public key not found

So basically if a signer public key is missing, we can't get the status
signature: empty "sigstatus" field in the JSON output, "Unknown
signature status" in Emacs.

IMHO this is a bug in gmime 2.6, and I think I know what causes it. I'll
file a bug in gmime and hopefully they'll find a cleaner way to fix it
than the one I came up with :)

> 
> > ---
> >  mime-node.c  |   50 ++-
> >  notmuch-client.h |   27 ++-
> >  notmuch-reply.c  |7 
> >  notmuch-show.c   |   97 
> > ++
> >  show-message.c   |4 ++
> >  5 files changed, 181 insertions(+), 4 deletions(-)
> > 
> > diff --git a/mime-node.c b/mime-node.c
> > index d26bb44..ae2473d 100644
> > --- a/mime-node.c
> > +++ b/mime-node.c
> > @@ -33,7 +33,11 @@ typedef struct mime_node_context {
> >  GMimeMessage *mime_message;
> >  
> >  /* Context provided by the caller. */
> > +#ifdef GMIME_26
> > +GMimeCryptoContext *cryptoctx;
> > +#else
> >  GMimeCipherContext *cryptoctx;
> > +#endif
> >  notmuch_bool_t decrypt;
> >  } mime_node_context_t;
> >  
> > @@ -57,8 +61,12 @@ _mime_node_context_free (mime_node_context_t *res)
> >  
> >  notmuch_status_t
> >  mime_node_open (const void *ctx, notmuch_message_t *message,
> > -   GMimeCipherContext *cryptoctx, notmuch_bool_t decrypt,
> > -   mime_node_t **root_out)
> > +#ifdef GMIME_26
> > +   GMimeCryptoContext *cryptoctx,
> > +#else
> > +   GMimeCipherContext *cryptoctx,
> > +#endif
> > +   notmuch_bool_t decrypt, mime_node_t **root_out)
> >  {
> >  const char *filename = notmuch_message_get_filename (message);
> >  mime_node_context_t *mctx;
> > @@ -112,12 +120,21 @@ DONE:
> >  return status;
> >  }
> >  
> > +#ifdef GMIME_26
> > +static int
> > +_signature_list_free (GMimeSignatureList **proxy)
> > +{
> > +g_object_unref (*proxy);
> > +return 0;
> > +}
> > +#else
> >  static int
> >  _signature_validity_free (GMimeSignatureValidity **proxy)
> >  {
> >  g_mime_signature_validity_free (*proxy);
> >  return 0;
> >  }
> > +#endif
> >  
> >  static mime_node_t *
> >  _mime_node_create (const mime_node_t *parent, GMimeObject *part)
> > @@ -165,11 +182,23 @@ _mime_node_create (const mime_node_t *parent, 
> > GMimeObject *part)
> > GMimeMultipartEncrypted *encrypteddata =
> > GMIME_MULTIPART_ENCRYPTED (part);
> > node->decrypt_attempted = TRUE;
> > +#ifdef GMIME_26
> > +   GMimeDecryptResult *decrypt_result = g_mime_decrypt_result_new ();
> 
> I think g_mime_multipart_encrypted_decrypt allocates the
> GMimeDecryptResult for you, so this will just leak memory.

You're right, fixed. Will it be freed along with node->decrypted_child,
or do we need to handle this ourself?

> 
> > +   node->decrypted_child = g_mime_multipart_encrypted_decrypt
> > +   (encrypteddata, node->ctx->cryptoctx, _result, );
> > +   if (node->decrypted_child) {
> > +   node->decrypt_success 

[PATCH] Add pseudo-compatibility with gmime 2.6

[Tim Stoakes]

Thomas Jost(schnouki at schnouki.net)@170112-00:56:
> There are lots of API changes in gmime 2.6 crypto handling. By adding
> preprocessor directives, it is however possible to add gmime 2.6 compatibility
> while preserving compatibility with gmime 2.4 too.
> 
> This is mostly based on id:"8762i8hrb9.fsf at bookbinder.fernseed.info".
> 
> This was tested against both gmime 2.6.4 and 2.4.31. With gmime 2.4.31, the
> crypto tests all work fine (as expected). With gmime 2.6.4, one crypto test
> fails (signature verification with signer key unavailable) but this will be 
> hard
> to fix since the new API does not report the reason why a signature 
> verification
> fails (other than the human-readable error message).

+1 from me.

I literally just coded up a similar patch, and the first email I see
with the newly compiled notmuch is this one. I've now tried Thomas's
(better) patch with gmime-2.6.4 and notmuch
7ddd849015759a329bf8fef8c8b5a93359408962, and can confirm it works fine
for me. This build breakage is otherwise quite painful.

Thanks Thomas.

Tim

-- 
Tim Stoakes

[PATCH] Add pseudo-compatibility with gmime 2.6

[Thomas Jost]

There are lots of API changes in gmime 2.6 crypto handling. By adding
preprocessor directives, it is however possible to add gmime 2.6 compatibility
while preserving compatibility with gmime 2.4 too.

This is mostly based on id:"8762i8hrb9.fsf at bookbinder.fernseed.info".

This was tested against both gmime 2.6.4 and 2.4.31. With gmime 2.4.31, the
crypto tests all work fine (as expected). With gmime 2.6.4, one crypto test
fails (signature verification with signer key unavailable) but this will be hard
to fix since the new API does not report the reason why a signature verification
fails (other than the human-readable error message).
---
 mime-node.c  |   50 ++-
 notmuch-client.h |   27 ++-
 notmuch-reply.c  |7 
 notmuch-show.c   |   97 ++
 show-message.c   |4 ++
 5 files changed, 181 insertions(+), 4 deletions(-)

diff --git a/mime-node.c b/mime-node.c
index d26bb44..ae2473d 100644
--- a/mime-node.c
+++ b/mime-node.c
@@ -33,7 +33,11 @@ typedef struct mime_node_context {
 GMimeMessage *mime_message;

 /* Context provided by the caller. */
+#ifdef GMIME_26
+GMimeCryptoContext *cryptoctx;
+#else
 GMimeCipherContext *cryptoctx;
+#endif
 notmuch_bool_t decrypt;
 } mime_node_context_t;

@@ -57,8 +61,12 @@ _mime_node_context_free (mime_node_context_t *res)

 notmuch_status_t
 mime_node_open (const void *ctx, notmuch_message_t *message,
-   GMimeCipherContext *cryptoctx, notmuch_bool_t decrypt,
-   mime_node_t **root_out)
+#ifdef GMIME_26
+   GMimeCryptoContext *cryptoctx,
+#else
+   GMimeCipherContext *cryptoctx,
+#endif
+   notmuch_bool_t decrypt, mime_node_t **root_out)
 {
 const char *filename = notmuch_message_get_filename (message);
 mime_node_context_t *mctx;
@@ -112,12 +120,21 @@ DONE:
 return status;
 }

+#ifdef GMIME_26
+static int
+_signature_list_free (GMimeSignatureList **proxy)
+{
+g_object_unref (*proxy);
+return 0;
+}
+#else
 static int
 _signature_validity_free (GMimeSignatureValidity **proxy)
 {
 g_mime_signature_validity_free (*proxy);
 return 0;
 }
+#endif

 static mime_node_t *
 _mime_node_create (const mime_node_t *parent, GMimeObject *part)
@@ -165,11 +182,23 @@ _mime_node_create (const mime_node_t *parent, GMimeObject 
*part)
GMimeMultipartEncrypted *encrypteddata =
GMIME_MULTIPART_ENCRYPTED (part);
node->decrypt_attempted = TRUE;
+#ifdef GMIME_26
+   GMimeDecryptResult *decrypt_result = g_mime_decrypt_result_new ();
+   node->decrypted_child = g_mime_multipart_encrypted_decrypt
+   (encrypteddata, node->ctx->cryptoctx, _result, );
+   if (node->decrypted_child) {
+   node->decrypt_success = node->verify_attempted = TRUE;
+   node->sig_list = g_mime_decrypt_result_get_signatures 
(decrypt_result);
+   if (!node->sig_list)
+   fprintf (stderr, "Failed to get signatures: %s\n",
+(err ? err->message : "no error explanation 
given"));
+#else
node->decrypted_child = g_mime_multipart_encrypted_decrypt
(encrypteddata, node->ctx->cryptoctx, );
if (node->decrypted_child) {
node->decrypt_success = node->verify_attempted = TRUE;
node->sig_validity = 
g_mime_multipart_encrypted_get_signature_validity (encrypteddata);
+#endif
} else {
fprintf (stderr, "Failed to decrypt part: %s\n",
 (err ? err->message : "no error explanation given"));
@@ -182,6 +211,18 @@ _mime_node_create (const mime_node_t *parent, GMimeObject 
*part)
 "(must be exactly 2)\n",
 node->nchildren);
} else {
+#ifdef GMIME_26
+   GMimeSignatureList *sig_list = g_mime_multipart_signed_verify
+   (GMIME_MULTIPART_SIGNED (part), node->ctx->cryptoctx, );
+   node->verify_attempted = TRUE;
+   node->sig_list = sig_list;
+   if (sig_list) {
+   GMimeSignatureList **proxy =
+   talloc (node, GMimeSignatureList *);
+   *proxy = sig_list;
+   talloc_set_destructor (proxy, _signature_list_free);
+   }
+#else
/* For some reason the GMimeSignatureValidity returned
 * here is not a const (inconsistent with that
 * returned by
@@ -200,10 +241,15 @@ _mime_node_create (const mime_node_t *parent, GMimeObject 
*part)
*proxy = sig_validity;
talloc_set_destructor (proxy, _signature_validity_free);
}
+#endif
}
 }

+#ifdef GMIME_26
+if (node->verify_attempted && !node->sig_list)
+#else
 if (node->verify_attempted && !node->sig_validity)
+#endif
fprintf (stderr, "Failed to verify signed part: %s\n",
 (err 

Re: [PATCH] Add pseudo-compatibility with gmime 2.6

[Thomas Jost]

On Mon, 16 Jan 2012 22:47:14 -0500, Austin Clements amdra...@mit.edu wrote:
 Quoth Thomas Jost on Jan 17 at 12:56 am:
  There are lots of API changes in gmime 2.6 crypto handling. By adding
  preprocessor directives, it is however possible to add gmime 2.6 
  compatibility
  while preserving compatibility with gmime 2.4 too.
 
 Awesome.  Comments inline below.

Thanks for reviewing this so quickly. Replies inline, and new patches
incoming soon.


  This is mostly based on id:8762i8hrb9@bookbinder.fernseed.info.
  
  This was tested against both gmime 2.6.4 and 2.4.31. With gmime 2.4.31, the
  crypto tests all work fine (as expected). With gmime 2.6.4, one crypto test
  fails (signature verification with signer key unavailable) but this will be 
  hard
  to fix since the new API does not report the reason why a signature 
  verification
  fails (other than the human-readable error message).
 
 What is the result of this failing test?

The test looks like that:

FAIL   signature verification with signer key unavailable
   --- crypto.4.expected   2012-01-16 23:05:06.765651183 +
   +++ crypto.4.output 2012-01-16 23:05:06.765651183 +
   @@ -12,9 +12,7 @@
 Bcc: ,
 Date: 01 Jan 2000 12:00:00 -},
 body: [{id: 1,
   - sigstatus: [{status: error,
   - keyid: 6D92612D94E46381,
   - errors: 2}],
   + sigstatus: [],
 content-type: multipart/signed,
 content: [{id: 2,
 content-type: text/plain,
   Failed to verify signed part: gpg: keyblock resource 
`/home/schnouki/dev/notmuch/test/tmp.crypto/gnupg/pubring.gpg': file open error
   gpg: armor header: Version: GnuPG v1.4.11 (GNU/Linux)
   gpg: Signature made Mon Jan 16 23:05:06 2012 UTC using RSA key ID 
94E46381
   gpg: Can't check signature: public key not found

So basically if a signer public key is missing, we can't get the status
signature: empty sigstatus field in the JSON output, Unknown
signature status in Emacs.

IMHO this is a bug in gmime 2.6, and I think I know what causes it. I'll
file a bug in gmime and hopefully they'll find a cleaner way to fix it
than the one I came up with :)

 
  ---
   mime-node.c  |   50 ++-
   notmuch-client.h |   27 ++-
   notmuch-reply.c  |7 
   notmuch-show.c   |   97 
  ++
   show-message.c   |4 ++
   5 files changed, 181 insertions(+), 4 deletions(-)
  
  diff --git a/mime-node.c b/mime-node.c
  index d26bb44..ae2473d 100644
  --- a/mime-node.c
  +++ b/mime-node.c
  @@ -33,7 +33,11 @@ typedef struct mime_node_context {
   GMimeMessage *mime_message;
   
   /* Context provided by the caller. */
  +#ifdef GMIME_26
  +GMimeCryptoContext *cryptoctx;
  +#else
   GMimeCipherContext *cryptoctx;
  +#endif
   notmuch_bool_t decrypt;
   } mime_node_context_t;
   
  @@ -57,8 +61,12 @@ _mime_node_context_free (mime_node_context_t *res)
   
   notmuch_status_t
   mime_node_open (const void *ctx, notmuch_message_t *message,
  -   GMimeCipherContext *cryptoctx, notmuch_bool_t decrypt,
  -   mime_node_t **root_out)
  +#ifdef GMIME_26
  +   GMimeCryptoContext *cryptoctx,
  +#else
  +   GMimeCipherContext *cryptoctx,
  +#endif
  +   notmuch_bool_t decrypt, mime_node_t **root_out)
   {
   const char *filename = notmuch_message_get_filename (message);
   mime_node_context_t *mctx;
  @@ -112,12 +120,21 @@ DONE:
   return status;
   }
   
  +#ifdef GMIME_26
  +static int
  +_signature_list_free (GMimeSignatureList **proxy)
  +{
  +g_object_unref (*proxy);
  +return 0;
  +}
  +#else
   static int
   _signature_validity_free (GMimeSignatureValidity **proxy)
   {
   g_mime_signature_validity_free (*proxy);
   return 0;
   }
  +#endif
   
   static mime_node_t *
   _mime_node_create (const mime_node_t *parent, GMimeObject *part)
  @@ -165,11 +182,23 @@ _mime_node_create (const mime_node_t *parent, 
  GMimeObject *part)
  GMimeMultipartEncrypted *encrypteddata =
  GMIME_MULTIPART_ENCRYPTED (part);
  node-decrypt_attempted = TRUE;
  +#ifdef GMIME_26
  +   GMimeDecryptResult *decrypt_result = g_mime_decrypt_result_new ();
 
 I think g_mime_multipart_encrypted_decrypt allocates the
 GMimeDecryptResult for you, so this will just leak memory.

You're right, fixed. Will it be freed along with node-decrypted_child,
or do we need to handle this ourself?

 
  +   node-decrypted_child = g_mime_multipart_encrypted_decrypt
  +   (encrypteddata, node-ctx-cryptoctx, decrypt_result, err);
  +   if (node-decrypted_child) {
  +   node-decrypt_success = node-verify_attempted = TRUE;
  +   node-sig_list = g_mime_decrypt_result_get_signatures 
  (decrypt_result);
  +   if (!node-sig_list)
  +   fprintf (stderr, Failed to get 

Re: [PATCH] Add pseudo-compatibility with gmime 2.6

[Austin Clements]

Quoth Thomas Jost on Jan 17 at 11:48 am:
 On Mon, 16 Jan 2012 22:47:14 -0500, Austin Clements amdra...@mit.edu wrote:
  Quoth Thomas Jost on Jan 17 at 12:56 am:
   This is mostly based on id:8762i8hrb9@bookbinder.fernseed.info.
   
   This was tested against both gmime 2.6.4 and 2.4.31. With gmime 2.4.31, 
   the
   crypto tests all work fine (as expected). With gmime 2.6.4, one crypto 
   test
   fails (signature verification with signer key unavailable) but this will 
   be hard
   to fix since the new API does not report the reason why a signature 
   verification
   fails (other than the human-readable error message).
  
  What is the result of this failing test?
 
 The test looks like that:
 
 FAIL   signature verification with signer key unavailable
--- crypto.4.expected   2012-01-16 23:05:06.765651183 +
+++ crypto.4.output 2012-01-16 23:05:06.765651183 +
@@ -12,9 +12,7 @@
  Bcc: ,
  Date: 01 Jan 2000 12:00:00 -},
  body: [{id: 1,
- sigstatus: [{status: error,
- keyid: 6D92612D94E46381,
- errors: 2}],
+ sigstatus: [],
  content-type: multipart/signed,
  content: [{id: 2,
  content-type: text/plain,
Failed to verify signed part: gpg: keyblock resource 
 `/home/schnouki/dev/notmuch/test/tmp.crypto/gnupg/pubring.gpg': file open 
 error
gpg: armor header: Version: GnuPG v1.4.11 (GNU/Linux)
gpg: Signature made Mon Jan 16 23:05:06 2012 UTC using RSA key ID 
 94E46381
gpg: Can't check signature: public key not found
 
 So basically if a signer public key is missing, we can't get the status
 signature: empty sigstatus field in the JSON output, Unknown
 signature status in Emacs.
 
 IMHO this is a bug in gmime 2.6, and I think I know what causes it. I'll
 file a bug in gmime and hopefully they'll find a cleaner way to fix it
 than the one I came up with :)

Oh, okay.  That does seem like a bug in GMime.  Do you think it would
be possible to mark this test as broken if notmuch is using GMime
2.6?  Off the top of my head, I can't think of an easy way to plumb
that information through to the test suite.  I don't think we should
push any patches that knowingly break a test, even if it's in just one
configuration.

  
   ---
mime-node.c  |   50 ++-
notmuch-client.h |   27 ++-
notmuch-reply.c  |7 
notmuch-show.c   |   97 
   ++
show-message.c   |4 ++
5 files changed, 181 insertions(+), 4 deletions(-)
   
   diff --git a/mime-node.c b/mime-node.c
   index d26bb44..ae2473d 100644
   --- a/mime-node.c
   +++ b/mime-node.c
   @@ -33,7 +33,11 @@ typedef struct mime_node_context {
GMimeMessage *mime_message;

/* Context provided by the caller. */
   +#ifdef GMIME_26
   +GMimeCryptoContext *cryptoctx;
   +#else
GMimeCipherContext *cryptoctx;
   +#endif
notmuch_bool_t decrypt;
} mime_node_context_t;

   @@ -57,8 +61,12 @@ _mime_node_context_free (mime_node_context_t *res)

notmuch_status_t
mime_node_open (const void *ctx, notmuch_message_t *message,
   - GMimeCipherContext *cryptoctx, notmuch_bool_t decrypt,
   - mime_node_t **root_out)
   +#ifdef GMIME_26
   + GMimeCryptoContext *cryptoctx,
   +#else
   + GMimeCipherContext *cryptoctx,
   +#endif
   + notmuch_bool_t decrypt, mime_node_t **root_out)
{
const char *filename = notmuch_message_get_filename (message);
mime_node_context_t *mctx;
   @@ -112,12 +120,21 @@ DONE:
return status;
}

   +#ifdef GMIME_26
   +static int
   +_signature_list_free (GMimeSignatureList **proxy)
   +{
   +g_object_unref (*proxy);
   +return 0;
   +}
   +#else
static int
_signature_validity_free (GMimeSignatureValidity **proxy)
{
g_mime_signature_validity_free (*proxy);
return 0;
}
   +#endif

static mime_node_t *
_mime_node_create (const mime_node_t *parent, GMimeObject *part)
   @@ -165,11 +182,23 @@ _mime_node_create (const mime_node_t *parent, 
   GMimeObject *part)
 GMimeMultipartEncrypted *encrypteddata =
 GMIME_MULTIPART_ENCRYPTED (part);
 node-decrypt_attempted = TRUE;
   +#ifdef GMIME_26
   + GMimeDecryptResult *decrypt_result = g_mime_decrypt_result_new ();
  
  I think g_mime_multipart_encrypted_decrypt allocates the
  GMimeDecryptResult for you, so this will just leak memory.
 
 You're right, fixed. Will it be freed along with node-decrypted_child,
 or do we need to handle this ourself?

That would be nice to know.  My guess would be that we have to free it
ourselves (or dereference it, at any rate), but the documentation
doesn't say.

 } else {
 fprintf (stderr, Failed to decrypt part: %s\n,
 

[PATCH] Add pseudo-compatibility with gmime 2.6

[Kazuo Teramoto]

On Tue, Jan 17, 2012 at 12:56:39AM +0100, Thomas Jost wrote:
> There are lots of API changes in gmime 2.6 crypto handling. By adding
> preprocessor directives, it is however possible to add gmime 2.6 compatibility
> while preserving compatibility with gmime 2.4 too.

I tested this with gmime 2.4.31 and 2.6.4. Works for me.

In a related note: Arch Linux started to ship gmime 2.6.4.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 

[PATCH] Add pseudo-compatibility with gmime 2.6

[Austin Clements]

Quoth Thomas Jost on Jan 17 at 12:56 am:
> There are lots of API changes in gmime 2.6 crypto handling. By adding
> preprocessor directives, it is however possible to add gmime 2.6 compatibility
> while preserving compatibility with gmime 2.4 too.

Awesome.  Comments inline below.

> This is mostly based on id:"8762i8hrb9.fsf at bookbinder.fernseed.info".
> 
> This was tested against both gmime 2.6.4 and 2.4.31. With gmime 2.4.31, the
> crypto tests all work fine (as expected). With gmime 2.6.4, one crypto test
> fails (signature verification with signer key unavailable) but this will be 
> hard
> to fix since the new API does not report the reason why a signature 
> verification
> fails (other than the human-readable error message).

What is the result of this failing test?

> ---
>  mime-node.c  |   50 ++-
>  notmuch-client.h |   27 ++-
>  notmuch-reply.c  |7 
>  notmuch-show.c   |   97 
> ++
>  show-message.c   |4 ++
>  5 files changed, 181 insertions(+), 4 deletions(-)
> 
> diff --git a/mime-node.c b/mime-node.c
> index d26bb44..ae2473d 100644
> --- a/mime-node.c
> +++ b/mime-node.c
> @@ -33,7 +33,11 @@ typedef struct mime_node_context {
>  GMimeMessage *mime_message;
>  
>  /* Context provided by the caller. */
> +#ifdef GMIME_26
> +GMimeCryptoContext *cryptoctx;
> +#else
>  GMimeCipherContext *cryptoctx;
> +#endif
>  notmuch_bool_t decrypt;
>  } mime_node_context_t;
>  
> @@ -57,8 +61,12 @@ _mime_node_context_free (mime_node_context_t *res)
>  
>  notmuch_status_t
>  mime_node_open (const void *ctx, notmuch_message_t *message,
> - GMimeCipherContext *cryptoctx, notmuch_bool_t decrypt,
> - mime_node_t **root_out)
> +#ifdef GMIME_26
> + GMimeCryptoContext *cryptoctx,
> +#else
> + GMimeCipherContext *cryptoctx,
> +#endif
> + notmuch_bool_t decrypt, mime_node_t **root_out)
>  {
>  const char *filename = notmuch_message_get_filename (message);
>  mime_node_context_t *mctx;
> @@ -112,12 +120,21 @@ DONE:
>  return status;
>  }
>  
> +#ifdef GMIME_26
> +static int
> +_signature_list_free (GMimeSignatureList **proxy)
> +{
> +g_object_unref (*proxy);
> +return 0;
> +}
> +#else
>  static int
>  _signature_validity_free (GMimeSignatureValidity **proxy)
>  {
>  g_mime_signature_validity_free (*proxy);
>  return 0;
>  }
> +#endif
>  
>  static mime_node_t *
>  _mime_node_create (const mime_node_t *parent, GMimeObject *part)
> @@ -165,11 +182,23 @@ _mime_node_create (const mime_node_t *parent, 
> GMimeObject *part)
>   GMimeMultipartEncrypted *encrypteddata =
>   GMIME_MULTIPART_ENCRYPTED (part);
>   node->decrypt_attempted = TRUE;
> +#ifdef GMIME_26
> + GMimeDecryptResult *decrypt_result = g_mime_decrypt_result_new ();

I think g_mime_multipart_encrypted_decrypt allocates the
GMimeDecryptResult for you, so this will just leak memory.

> + node->decrypted_child = g_mime_multipart_encrypted_decrypt
> + (encrypteddata, node->ctx->cryptoctx, _result, );
> + if (node->decrypted_child) {
> + node->decrypt_success = node->verify_attempted = TRUE;
> + node->sig_list = g_mime_decrypt_result_get_signatures 
> (decrypt_result);
> + if (!node->sig_list)
> + fprintf (stderr, "Failed to get signatures: %s\n",
> +  (err ? err->message : "no error explanation 
> given"));

My understanding is that g_mime_decrypt_result_get_signatures returns
NULL if there are no signatures and that this isn't an error.  This
differs from 2.4, which would return an empty but non-NULL list.

Also, I believe you have to free the sig_list in both branches now,
which means the talloc_set_destructor can be moved to common logic
outside of the if decrypted/signed.

> +#else
>   node->decrypted_child = g_mime_multipart_encrypted_decrypt
>   (encrypteddata, node->ctx->cryptoctx, );
>   if (node->decrypted_child) {
>   node->decrypt_success = node->verify_attempted = TRUE;
>   node->sig_validity = 
> g_mime_multipart_encrypted_get_signature_validity (encrypteddata);
> +#endif

It's confusing to have the open braces in the #ifdef'd region with a
matching close brace outside of it (and I imagine this confuses
editors and uncrustify, too).  You could either copy the else part in
both branches of the #ifdef or avoid duplicated code with something
like

#ifdef GMIME_26
  .. node->decrypted_child = ..
#else
  .. node->decrypted_child = ..
#endif
  if (node->decrypted_child) {
node->decrypt_success = node->verify_attempted = TRUE;
#ifdef GMIME_26
node->sig_list = ..
#else
node->sig_validity = ..
#endif
  } else {
fprintf (stderr, ..);
  }

>   } else {
>   fprintf (stderr, "Failed to decrypt part: %s\n",
>

[PATCH] Add pseudo-compatibility with gmime 2.6

[Thomas Jost]

There are lots of API changes in gmime 2.6 crypto handling. By adding
preprocessor directives, it is however possible to add gmime 2.6 compatibility
while preserving compatibility with gmime 2.4 too.

This is mostly based on id:8762i8hrb9@bookbinder.fernseed.info.

This was tested against both gmime 2.6.4 and 2.4.31. With gmime 2.4.31, the
crypto tests all work fine (as expected). With gmime 2.6.4, one crypto test
fails (signature verification with signer key unavailable) but this will be hard
to fix since the new API does not report the reason why a signature verification
fails (other than the human-readable error message).
---
 mime-node.c  |   50 ++-
 notmuch-client.h |   27 ++-
 notmuch-reply.c  |7 
 notmuch-show.c   |   97 ++
 show-message.c   |4 ++
 5 files changed, 181 insertions(+), 4 deletions(-)

diff --git a/mime-node.c b/mime-node.c
index d26bb44..ae2473d 100644
--- a/mime-node.c
+++ b/mime-node.c
@@ -33,7 +33,11 @@ typedef struct mime_node_context {
 GMimeMessage *mime_message;
 
 /* Context provided by the caller. */
+#ifdef GMIME_26
+GMimeCryptoContext *cryptoctx;
+#else
 GMimeCipherContext *cryptoctx;
+#endif
 notmuch_bool_t decrypt;
 } mime_node_context_t;
 
@@ -57,8 +61,12 @@ _mime_node_context_free (mime_node_context_t *res)
 
 notmuch_status_t
 mime_node_open (const void *ctx, notmuch_message_t *message,
-   GMimeCipherContext *cryptoctx, notmuch_bool_t decrypt,
-   mime_node_t **root_out)
+#ifdef GMIME_26
+   GMimeCryptoContext *cryptoctx,
+#else
+   GMimeCipherContext *cryptoctx,
+#endif
+   notmuch_bool_t decrypt, mime_node_t **root_out)
 {
 const char *filename = notmuch_message_get_filename (message);
 mime_node_context_t *mctx;
@@ -112,12 +120,21 @@ DONE:
 return status;
 }
 
+#ifdef GMIME_26
+static int
+_signature_list_free (GMimeSignatureList **proxy)
+{
+g_object_unref (*proxy);
+return 0;
+}
+#else
 static int
 _signature_validity_free (GMimeSignatureValidity **proxy)
 {
 g_mime_signature_validity_free (*proxy);
 return 0;
 }
+#endif
 
 static mime_node_t *
 _mime_node_create (const mime_node_t *parent, GMimeObject *part)
@@ -165,11 +182,23 @@ _mime_node_create (const mime_node_t *parent, GMimeObject 
*part)
GMimeMultipartEncrypted *encrypteddata =
GMIME_MULTIPART_ENCRYPTED (part);
node-decrypt_attempted = TRUE;
+#ifdef GMIME_26
+   GMimeDecryptResult *decrypt_result = g_mime_decrypt_result_new ();
+   node-decrypted_child = g_mime_multipart_encrypted_decrypt
+   (encrypteddata, node-ctx-cryptoctx, decrypt_result, err);
+   if (node-decrypted_child) {
+   node-decrypt_success = node-verify_attempted = TRUE;
+   node-sig_list = g_mime_decrypt_result_get_signatures 
(decrypt_result);
+   if (!node-sig_list)
+   fprintf (stderr, Failed to get signatures: %s\n,
+(err ? err-message : no error explanation 
given));
+#else
node-decrypted_child = g_mime_multipart_encrypted_decrypt
(encrypteddata, node-ctx-cryptoctx, err);
if (node-decrypted_child) {
node-decrypt_success = node-verify_attempted = TRUE;
node-sig_validity = 
g_mime_multipart_encrypted_get_signature_validity (encrypteddata);
+#endif
} else {
fprintf (stderr, Failed to decrypt part: %s\n,
 (err ? err-message : no error explanation given));
@@ -182,6 +211,18 @@ _mime_node_create (const mime_node_t *parent, GMimeObject 
*part)
 (must be exactly 2)\n,
 node-nchildren);
} else {
+#ifdef GMIME_26
+   GMimeSignatureList *sig_list = g_mime_multipart_signed_verify
+   (GMIME_MULTIPART_SIGNED (part), node-ctx-cryptoctx, err);
+   node-verify_attempted = TRUE;
+   node-sig_list = sig_list;
+   if (sig_list) {
+   GMimeSignatureList **proxy =
+   talloc (node, GMimeSignatureList *);
+   *proxy = sig_list;
+   talloc_set_destructor (proxy, _signature_list_free);
+   }
+#else
/* For some reason the GMimeSignatureValidity returned
 * here is not a const (inconsistent with that
 * returned by
@@ -200,10 +241,15 @@ _mime_node_create (const mime_node_t *parent, GMimeObject 
*part)
*proxy = sig_validity;
talloc_set_destructor (proxy, _signature_validity_free);
}
+#endif
}
 }
 
+#ifdef GMIME_26
+if (node-verify_attempted  !node-sig_list)
+#else
 if (node-verify_attempted  !node-sig_validity)
+#endif
fprintf (stderr, Failed to verify signed part: %s\n,
 (err ? err-message : no error 

Re: [PATCH] Add pseudo-compatibility with gmime 2.6

[Kazuo Teramoto]

On Tue, Jan 17, 2012 at 12:56:39AM +0100, Thomas Jost wrote:
 There are lots of API changes in gmime 2.6 crypto handling. By adding
 preprocessor directives, it is however possible to add gmime 2.6 compatibility
 while preserving compatibility with gmime 2.4 too.

I tested this with gmime 2.4.31 and 2.6.4. Works for me.

In a related note: Arch Linux started to ship gmime 2.6.4.


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

Re: [PATCH] Add pseudo-compatibility with gmime 2.6

[Austin Clements]

Quoth Thomas Jost on Jan 17 at 12:56 am:
 There are lots of API changes in gmime 2.6 crypto handling. By adding
 preprocessor directives, it is however possible to add gmime 2.6 compatibility
 while preserving compatibility with gmime 2.4 too.

Awesome.  Comments inline below.

 This is mostly based on id:8762i8hrb9@bookbinder.fernseed.info.
 
 This was tested against both gmime 2.6.4 and 2.4.31. With gmime 2.4.31, the
 crypto tests all work fine (as expected). With gmime 2.6.4, one crypto test
 fails (signature verification with signer key unavailable) but this will be 
 hard
 to fix since the new API does not report the reason why a signature 
 verification
 fails (other than the human-readable error message).

What is the result of this failing test?

 ---
  mime-node.c  |   50 ++-
  notmuch-client.h |   27 ++-
  notmuch-reply.c  |7 
  notmuch-show.c   |   97 
 ++
  show-message.c   |4 ++
  5 files changed, 181 insertions(+), 4 deletions(-)
 
 diff --git a/mime-node.c b/mime-node.c
 index d26bb44..ae2473d 100644
 --- a/mime-node.c
 +++ b/mime-node.c
 @@ -33,7 +33,11 @@ typedef struct mime_node_context {
  GMimeMessage *mime_message;
  
  /* Context provided by the caller. */
 +#ifdef GMIME_26
 +GMimeCryptoContext *cryptoctx;
 +#else
  GMimeCipherContext *cryptoctx;
 +#endif
  notmuch_bool_t decrypt;
  } mime_node_context_t;
  
 @@ -57,8 +61,12 @@ _mime_node_context_free (mime_node_context_t *res)
  
  notmuch_status_t
  mime_node_open (const void *ctx, notmuch_message_t *message,
 - GMimeCipherContext *cryptoctx, notmuch_bool_t decrypt,
 - mime_node_t **root_out)
 +#ifdef GMIME_26
 + GMimeCryptoContext *cryptoctx,
 +#else
 + GMimeCipherContext *cryptoctx,
 +#endif
 + notmuch_bool_t decrypt, mime_node_t **root_out)
  {
  const char *filename = notmuch_message_get_filename (message);
  mime_node_context_t *mctx;
 @@ -112,12 +120,21 @@ DONE:
  return status;
  }
  
 +#ifdef GMIME_26
 +static int
 +_signature_list_free (GMimeSignatureList **proxy)
 +{
 +g_object_unref (*proxy);
 +return 0;
 +}
 +#else
  static int
  _signature_validity_free (GMimeSignatureValidity **proxy)
  {
  g_mime_signature_validity_free (*proxy);
  return 0;
  }
 +#endif
  
  static mime_node_t *
  _mime_node_create (const mime_node_t *parent, GMimeObject *part)
 @@ -165,11 +182,23 @@ _mime_node_create (const mime_node_t *parent, 
 GMimeObject *part)
   GMimeMultipartEncrypted *encrypteddata =
   GMIME_MULTIPART_ENCRYPTED (part);
   node-decrypt_attempted = TRUE;
 +#ifdef GMIME_26
 + GMimeDecryptResult *decrypt_result = g_mime_decrypt_result_new ();

I think g_mime_multipart_encrypted_decrypt allocates the
GMimeDecryptResult for you, so this will just leak memory.

 + node-decrypted_child = g_mime_multipart_encrypted_decrypt
 + (encrypteddata, node-ctx-cryptoctx, decrypt_result, err);
 + if (node-decrypted_child) {
 + node-decrypt_success = node-verify_attempted = TRUE;
 + node-sig_list = g_mime_decrypt_result_get_signatures 
 (decrypt_result);
 + if (!node-sig_list)
 + fprintf (stderr, Failed to get signatures: %s\n,
 +  (err ? err-message : no error explanation 
 given));

My understanding is that g_mime_decrypt_result_get_signatures returns
NULL if there are no signatures and that this isn't an error.  This
differs from 2.4, which would return an empty but non-NULL list.

Also, I believe you have to free the sig_list in both branches now,
which means the talloc_set_destructor can be moved to common logic
outside of the if decrypted/signed.

 +#else
   node-decrypted_child = g_mime_multipart_encrypted_decrypt
   (encrypteddata, node-ctx-cryptoctx, err);
   if (node-decrypted_child) {
   node-decrypt_success = node-verify_attempted = TRUE;
   node-sig_validity = 
 g_mime_multipart_encrypted_get_signature_validity (encrypteddata);
 +#endif

It's confusing to have the open braces in the #ifdef'd region with a
matching close brace outside of it (and I imagine this confuses
editors and uncrustify, too).  You could either copy the else part in
both branches of the #ifdef or avoid duplicated code with something
like

#ifdef GMIME_26
  .. node-decrypted_child = ..
#else
  .. node-decrypted_child = ..
#endif
  if (node-decrypted_child) {
node-decrypt_success = node-verify_attempted = TRUE;
#ifdef GMIME_26
node-sig_list = ..
#else
node-sig_validity = ..
#endif
  } else {
fprintf (stderr, ..);
  }

   } else {
   fprintf (stderr, Failed to decrypt part: %s\n,
(err ? err-message : no error explanation given));
 @@ -182,6 +211,18 @@ _mime_node_create (const mime_node_t *parent,