notmuch/test/T356-protected-headers.sh, branch 0.32

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/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

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

tests: disable CRL checks from gpgsm

2020-04-30T21:02:38Z

GPGME has a strange failure mode when it is in offline mode, and/or when certificates don't have any CRLs: in particular, it refuses to accept the validity of any certificate other than a "root" cert. This can be worked around by setting the `disable-crl-checks` configuration variable for gpgsm. I've reported this to the GPGME upstream at https://dev.gnupg.org/T4883, but I have no idea how it will be resolved. In the meantime, we'll just work around it. Note that this fixes the test for verification of id:smime-multipart-signed@protected-headers.example, because multipart/signed messages are already handled correctly (one-part PKCS#7 messages will get fixed later). Signed-off-by: Daniel Kahn Gillmor

test/protected-headers: Add tests for S/MIME protected headers

2020-04-30T20:57:37Z

Recognize the protected subject for S/MIME example protected header messages. Signed-off-by: Daniel Kahn Gillmor

index: avoid indexing legacy-display parts

2019-09-01T11:45:30Z

When we notice a legacy-display part during indexing, it makes more sense to avoid indexing it as part of the message body. Given that the protected subject will already be indexed, there is no need to index this part at all, so we skip over it. If this happens during indexing, we set a property on the message: index.repaired=skip-protected-headers-legacy-display Signed-off-by: Daniel Kahn Gillmor

cli/{show,reply}: skip over legacy-display parts

2019-09-01T11:44:17Z

Make use of the previous changes to fast-forward past any legacy-display parts during "notmuch show" and "notmuch reply". Signed-off-by: Daniel Kahn Gillmor

test: avoid showing legacy-display parts

2019-09-01T11:32:56Z

Enigmail generates a "legacy-display" part when it sends encrypted mail with a protected Subject: header. This part is intended to display the Subject for mail user agents that are capable of decryption, but do not know how to deal with embedded protected headers. This part is the first child of a two-part multipart/mixed cryptographic payload within a cryptographic envelope that includes encryption (that is, it is not just a cleartext signed message). It uses Content-Type: text/rfc822-headers. That is: A └┬╴multipart/encrypted B ├─╴application/pgp-encrypted C └┬╴application/octet-stream * ╤ D └┬╴multipart/mixed; protected-headers=v1 (cryptographic payload) E ├─╴text/rfc822-headers; protected-headers=v1 (legacy-display part) F └─╴… (actual message body) In discussions with jrollins, i've come to the conclusion that a legacy-display part should be stripped entirely from "notmuch show" and "notmuch reply" now that these tools can understand and interpret protected headers. You can tell when a message part is a protected header part this way: * is the payload (D) multipart/mixed with exactly two children? * is its first child (E) Content-Type: text/rfc822-headers? * does the first child (E) have the property protected-headers=v1? * do all the headers in the body of the first child (E) match the protected headers in the payload part (D) itself? If this is the case, and we already know how to deal with the protected header, then there is no reason to try to render the legacy-display part itself for the user. Furthermore, when indexing, if we are indexing properly, we should avoid indexing the text in E as part of the message body. 'notmuch reply' is an interesting case: the standard use of 'notmuch reply' will end up omitting all mention of protected Subject:. The right fix is for the replying MUA to be able to protect its headers, and for it to set them appropriately based on headers found in the original message. If a replying MUA is unable to protect headers, but still wants the user to be able to see the original header, a replying MUA that notices that the original message's subject differs from the proposed reply subject may choose to include the original's subject in the quoted/attributed text. (this would be a stopgap measure; it's not even clear that there is user demand for it) This test suite change indicates what we want to happen for this case (the tests are currently broken), and includes three additional TODO suggestions of subtle cases for anyone who wants to flesh out the test suite even further. (i believe all these cases should be already fixed by the rest of this series, but haven't had time to write the tests for the unusual cases) Signed-off-by: Daniel Kahn Gillmor

cli/reply: pull proposed subject line from the message, not the index

2019-05-29T11:17:33Z

Protected subject lines were being emitted in reply when the cleartext of documents was indexed. create_reply_message() was pulling the subject line from the index, rather than pulling it from the GMimeMessage object that it already has on hand. This one-line fix to notmuch-reply.c solves that problem, and doesn't cause any additional tests to fail. Signed-off-by: Daniel Kahn Gillmor

test: reply (in cli and emacs) should protect indexed sensitive headers

2019-05-29T11:17:20Z

These tests are currently broken! When a protected subject is indexed in the clear, it leaks in the reply headers :( For emacs, we set up separate tests for when the protected header is indexed in the clear and when it is unindexed. neither case should leak, but the former wasn't tested yet. We will fix the two broken tests in a subsequent patch. Signed-off-by: Daniel Kahn Gillmor