[PATCH] Add pseudo-compatibility with gmime 2.6
Thomas Jost
schnouki at schnouki.net
Thu Jan 19 15:52:47 PST 2012
On Tue, 17 Jan 2012 15:38:36 -0500, Austin Clements <amdragon at MIT.EDU> wrote:
> Quoth Thomas Jost on Jan 17 at 11:48 am:
> > On Mon, 16 Jan 2012 22:47:14 -0500, Austin Clements <amdragon at MIT.EDU> 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 +0000
> > +++ crypto.4.output 2012-01-16 23:05:06.765651183 +0000
> > @@ -12,9 +12,7 @@
> > "Bcc": "",
> > "Date": "01 Jan 2000 12:00:00 -0000"},
> > "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: <http://notmuchmail.org/pipermail/notmuch/attachments/20120120/1544b0d5/attachment.pgp>
More information about the notmuch
mailing list