On Tue, 17 Jan 2012 15:38:36 -0500, Austin Clements <amdragon@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@MIT.EDU> wrote:
> > > Quoth Thomas Jost on Jan 17 at 12:56 am:
> > > > This is mostly based on id:"8762i8hrb9.fsf@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