From: Jameson Graef Rollins <jrollins@finestructure.net>
To: "Bryant\, Daniel B." <Dan.Bryant@jhuapl.edu>,
	Notmuch Mail <notmuch@notmuchmail.org>
Subject: RE: S/MIME support
In-Reply-To:
 <24CAA033F4DBCD4DB53CBFB11AEF037C1044F0566F@aplesrepublic.dom1.jhuapl.edu>
References: <1340995101-9616-1-git-send-email-jrollins@finestructure.net>
	<24CAA033F4DBCD4DB53CBFB11AEF037C1044F0566F@aplesrepublic.dom1.jhuapl.edu>
User-Agent: Notmuch/0.13.2+54~ga0426dc (http://notmuchmail.org) Emacs/23.4.1
	(x86_64-pc-linux-gnu)
Date: Tue, 10 Jul 2012 00:40:03 -0700
Message-ID: <87hatgysh8.fsf@servo.finestructure.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha256; protocol="application/pgp-signature"
Precedence: list

--=-=-=
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 09 2012, "Bryant, Daniel B." <Dan.Bryant@jhuapl.edu> wrote:
> I was able to get signature verification working with your patchset
> (with a caveat) but not decryption.

Hi, Daniel.  I guess I'm only partially happy to hear that!  I
definitely do appreciate the feedback, though.

> The caveat is that GMime is still borked with handling signatures with
> content type application/x-pkcs7-signature
> (vs. application/pkcs7-signature, which works fine). This is upstream
> GNOME bug #674032 that was supposed to have been fixed in GMime 2.6.9,
> but that original fix is also broken.

Ah, I didn't notice that:

https://bugzilla.gnome.org/show_bug.cgi?id=3D674032

Encouragingly, it sounds like Jeffery is working on it.

> One possible workaround is to twiddle the content-type of the
> signature part (and the corresponding protocol in the multipart/signed
> part). I implemented this by looping over each message part in
> mime_node_open() and modifying as necessary using the following logic:
>
>
>     GMimeContentType *content_type =3D g_mime_object_get_content_type (pa=
rt);
>
>     const char *subtype =3D g_mime_content_type_get_media_subtype (conten=
t_type);
>     const char *protocol =3D g_mime_content_type_get_parameter (content_t=
ype, "protocol");
>
>     if (!strcmp(subtype, "x-pkcs7-signature")) {
>         g_mime_content_type_set_media_subtype (content_type, "pkcs7-signa=
ture");
>     }
>
>     if (protocol && !strcmp(protocol, "application/x-pkcs7-signature")) {
>         g_mime_content_type_set_parameter (content_type, "protocol","appl=
ication/pkcs7-signature");
>     }=20=20=20=20

We could do this, but I would certainly prefer that we fix gmime to
handle both types properly.

> All of my S/MIME encrypted mail consists of single part messages with
> content-type "application/x-pkcs7-mime". These conform to RFC3851,
> section 3.3/3.4. (sample messages are included in the RFC as
> well). This fails to be decrypted by notmuch because the mime node
> traversal code assumes that every encrypted message is
> multipart/encrypted, which appears to only be true for PGP/MIME.

Thanks for the great example of why we need tests!

Would you (or anyone) be willing to start putting together some tests
that include messages encrypted according to this RFC?  I think adding
some tests to the test/crypto script would be a great place to start.

jamie.

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJP+9xTAAoJEO00zqvie6q8V+EP/jhoBnmPDq9Y9ZdFjaB2dUoz
8ywPcDyBsWHOKTMqlhoh2j9POOJkHR6lMQEekAjfJxpfTTqBvVDtGKXH5fzWZKwT
giVaS6aCZeeFxjZU0y7iKHRsbjemeSv/9dv0FpHxMt4hEcNsduRLx89+xfARhRmg
jcLwTjAAaSVTIJagElvImZLxLr3URUptRDN+x590PylA3ZeM0mLf5mlMdem72cT9
jepcYQLxg4p1v/d2Tz68n9JmqOqH0bX/Aq5A0NJ9aKP1rxyJsSM3cXPqGNRccK8Q
RUVmCVTTgmOCFvI17cLTSd8gP9ikJ6P5ZZmsL5PmuyfjbctY5m6Y8mYEO636s62J
RrEuPoZV1UjrmIVR9dmsASfB/j8wKkMvlRzaMrdmcOl2wHzI47VdCVT51lf2Tpib
J3LqwIvcqqHN+qhVkvBlCtX4xz+cwwZxJMapg9W3Q53QKh/RowH4dzxCe+Catudg
G3hMBkaBOGNe2tEGEvxgDTyE2pmFCNkkM9eAKyvn2wqtsX3ACEajvkFsyC4y6A0c
wapKavsimz3AKpYypFcqHsSoGbFKghqzEitqIjXXZRDWkxTa6Kohk9Newlwj9nW0
arejsCUrYkPeHeOkFVVKapKczfOdVOaaNLApOnd6jefy0aZh7ce8wHQjiMyzW81P
bvU7UZ/zFWSkdsU4sHIM
=35NF
-----END PGP SIGNATURE-----
--=-=-=--