notmuch/test/T355-smime.sh, branch 0.32

T355: specify hash algorithm explicitly

2020-08-08T19:04:27Z

On some systems (notably, the one shipped with LibreSSL), default fingerprint digest algorithm is SHA256. On other systems, users can change default digest algorithm by changing default_md in /etc/ssl/default_md. Let's ask openssl to provide us specific algorithm to make the test more deterministic. Signed-off-by: Đoàn Trần Công Danh

test: mark two tests broken on machines with 32 bit time_t

2020-06-27T01:16:51Z

I haven't traced the code path as exhaustively for the SMIME test, but the expiry date in question is larger then representable in a signed 32 bit integer.

smime: Index cleartext of envelopedData when requested

2020-05-23T01:12:00Z

Signed-off-by: Daniel Kahn Gillmor

smime: Pass PKCS#7 envelopedData to node_decrypt_and_verify

2020-05-23T01:11:51Z

This change means we can support "notmuch show --decrypt=true" for S/MIME encrypted messages, resolving several outstanding broken tests, including all the remaining S/MIME protected header examples. We do not yet handle indexing the cleartext of S/MIME encrypted messages, though. Signed-off-by: Daniel Kahn Gillmor

cli/reply: Ignore PKCS#7 wrapper parts when replying

2020-05-23T01:11:25Z

When composing a reply, no one wants to see this line in the proposed message: Non-text part: application/pkcs7-mime So we hide it, the same way we hide PGP/MIME cruft. Signed-off-by: Daniel Kahn Gillmor

cli/show: If a leaf part has children, show them instead of omitting

2020-05-23T01:11:17Z

Until we did PKCS#7 unwrapping, no leaf MIME part could have a child. Now, we treat the unwrapped MIME part as the child of the PKCS#7 SignedData object. So in that case, we want to show it instead of deliberately omitting the content. This fixes the test of the protected subject in id:smime-onepart-signed@protected-headers.example. Signed-off-by: Daniel Kahn Gillmor

cli: include wrapped part of PKCS#7 SignedData in the MIME tree

2020-05-23T01:11:07Z

Unwrap a PKCS#7 SignedData part unconditionally when the cli is traversing the MIME tree, and return it as a "child" of what would otherwise be a leaf in the tree. Unfortunately, this also breaks the JSON output. We will fix that next. Signed-off-by: Daniel Kahn Gillmor

smime: Identify encrypted S/MIME parts during indexing

2020-05-23T01:10:55Z

We don't handle them correctly yet, but we can at least mark them as being encrypted. Signed-off-by: Daniel Kahn Gillmor

lib: index PKCS7 SignedData parts

2020-05-23T01:10:46Z

When we are indexing, we should treat SignedData parts the same way that we treat a multipart object, indexing the wrapped part as a distinct MIME object. Unfortunately, this means doing some sort of cryptographic verification whose results we throw away, because GMime doesn't offer us any way to unwrap without doing signature verification. I've opened https://github.com/jstedfast/gmime/issues/67 to request the capability from GMime but for now, we'll just accept the additional performance hit. As we do this indexing, we also apply the "signed" tag, by analogy with how we handle multipart/signed messages. These days, that kind of change should probably be done with a property instead, but that's a different set of changes. This one is just for consistency. Note that we are currently *only* handling signedData parts, which are basically clearsigned messages. PKCS#7 parts can also be envelopedData and authEnvelopedData (which are effectively encryption layers), and compressedData (which afaict isn't implemented anywhere, i've never encountered it). We're laying the groundwork for indexing these other S/MIME types here, but we're only dealing with signedData for now. Signed-off-by: Daniel Kahn Gillmor

smime: tests of X.509 certificate validity are known-broken on GMime < 3.2.7

2020-05-23T01:04:57Z

When checking cryptographic signatures, Notmuch relies on GMime to tell it whether the certificate that signs a message has a valid User ID or not. If the User ID is not valid, then notmuch does not report the signer's User ID to the user. This means that the consumer of notmuch's cryptographic summary of a message (or of its protected headers) can be confident in relaying the reported identity to the user. However, some versions of GMime before 3.2.7 cannot report Certificate validity for X.509 certificates. This is resolved upstream in GMime at https://github.com/jstedfast/gmime/pull/90. We adapt to this by marking tests of reported User IDs for S/MIME-signed messages as known-broken if GMime is older than 3.2.7 and has not been patched. If GMime >= 3.2.7 and certificate validity still doesn't work for X.509 certs, then there has likely been a regression in GMime and we should fail early, during ./configure. To break out these specific User ID checks from other checks, i had to split some tests into two parts, and reuse $output across the two subtests. Signed-off-by: Daniel Kahn Gillmor