Handle PKCS#7 S/MIME messages

[Tomi Ollila]

On Mon, May 04 2020, Daniel Kahn Gillmor wrote:

> Hi Tomi--
>
> On Sat 2020-05-02 00:15:57 +0300, Tomi Ollila wrote:
>> I did not see anything suspicious in code, but
>>
>> I got these test failures:
>>
>> in ubuntu 19.10 native environment, and
>>
>> in debian 10 (podman) container running in fedora 31 system
>>
>>
>> T355-smime: Testing S/MIME signature verification and decryption
>>  FAIL   Verify signature on PKCS#7 SignedData message
>>  crypto: value not equal: data[0][0][0]["crypto"]["signed"]["status"][0] =
>>  {'status': 'good', 
>>   'fingerprint': '702BA4B157F1E2B7D16B0C6A5FFC8A7DE2057DEB', 
>>   'created': 1574813489,
>>   'expires': 2611032858} != 
>>  {'created': 1574813489, 
>>   'expires': 2611032858,
>>   'fingerprint': '702BA4B157F1E2B7D16B0C6A5FFC8A7DE2057DEB', 
>>   'userid': 'CN=Alice Lovelace', 
>>   'status': 'good'}
>>
>> T356-protected-headers: Testing Message decryption with protected headers
>>  FAIL   verify signed PKCS#7 subject (multipart-signed)
>>  sig_uid: object not found:  data[0][0][0]["crypto"]["signed"]["status"][0]["userid"]
>>  FAIL   verify signed PKCS#7 subject (onepart-signed)
>>  sig_uid: object not found: data[0][0][0]["crypto"]["signed"]["status"][0]["userid"]
>>  FAIL   confirm signed and encrypted PKCS#7 subject (sign+enc)
>>  sig_uid: object not found: data[0][0][0]["crypto"]["signed"]["status"][0]["userid"]
>>  FAIL   confirm signed and encrypted PKCS#7 subject (sign+enc+legacy-disp)
>>  sig_uid: object not found: data[0][0][0]["crypto"]["signed"]["status"][0]["userid"]
>
> Thanks for identifying these.  These are problems related to a bug in
> the released version of GMime on those platforms.  Unfixed versions of
> gmime cannot report *any* certificate validity for X.509 certificates:
>
>    https://github.com/jstedfast/gmime/pull/90
>
> The fix for gmime is pretty simple, but it's not something we can
> address directly in notmuch.
>
> The fix was first released in GMime version 3.2.7, but it was first in
> debian in gmime 3.2.6-2, and should be relatively easy to backport for
> any distro that wants it (i suppose i could probably get it into the
> next point release for debian 10 as well, since it is a bugfix for an
> already-exposed API).
>
> So, how should we deal with this in notmuch?  It seems a bit silly to
> bump our required version of gmime to the (relatively new) version
> 3.2.7, for a fix for a cornercase of a novel use case.
>
> Maybe the test suite should change based on version of GMime?  That
> would cause problems for distros that backport the GMime fix, though.
>
> I guess i could write a reproducer for the gmime issue and we could
> include it in ./configure, and modify the test suite on that basis.

Reproducer in case gmime version is less than 3.2.7 -- with newer
gmimes that has to work so if that ever broke in newer gmimes we'd
notice (reproducer could hide that).

>
> Any other suggestions?
>
>     --dkg

Tomi