From: Thomas Jost <schnouki@schnouki.net>
To: Austin Clements <amdragon@MIT.EDU>
Subject: Re: [PATCH] Add pseudo-compatibility with gmime 2.6
In-Reply-To: <20120117203836.GR16740@mit.edu>
References: <8762gbtd6p.fsf@schnouki.net>
	<1326758199-18058-1-git-send-email-schnouki@schnouki.net>
	<20120117034714.GG16740@mit.edu> <8739bea9lc.fsf@thor.loria.fr>
	<20120117203836.GR16740@mit.edu>
User-Agent: Notmuch/0.11+95~g205cf08 (http://notmuchmail.org) Emacs/24.0.92.1
	(x86_64-unknown-linux-gnu)
Date: Fri, 20 Jan 2012 00:52:47 +0100
Message-ID: <87k44n2qsw.fsf@schnouki.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
Cc: notmuch@notmuchmail.org
Precedence: list

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tue, 17 Jan 2012 15:38:36 -0500, Austin Clements <amdragon@MIT.EDU> wrot=
e:
> 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=
".
> > > >=20
> > > > 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 cry=
pto 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).
> > >=20
> > > What is the result of this failing test?
> >=20
> > The test looks like that:
> >=20
> >         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/schn=
ouki/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 I=
D 94E46381
> >        gpg: Can't check signature: public key not found
> >=20
> > 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.
> >=20
> > 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 :)
>=20
> 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)
> > >=20
> > > 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.
> >=20
> > That sound right. The weird part is that it did not cause anything to
> > fail in the test suite...
>=20
> 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,

=2D-=20
Thomas/Schnouki

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJPGKzPAAoJEMPdciX+bh5Ij/IIAKInyX1Xwx1V7+Rpzn7G+459
gWB2IX78m1bhCU8xEMqYlCqBDNxOQDOY2tIPYKxK3IwxTzGfG5DXTnANc7pNV0xz
Ukt7VbOChurmllBhXzyqij+DQRo8KUfekZAuM6D1ZCj48WpD4o2v7eRM3YFwji7d
fLZA5OU9e1BIyN6nyvXthq2PJF/0xkgK6NjUKdg3A7HYbPSZyDHuQ497beaBh49J
dm3je5UQzWCozyDAczj7CIOtvB81ztCpVckKrL6lawZ142OSTth+y6Wy+wdJ6zoI
veAeP5O2AVTot3W7Z7DdW6BNslbd67UGrhwI2zPJ7fDGk+fOK56KbFTFwIEEroU=
=Y0t7
-----END PGP SIGNATURE-----
--=-=-=--