notmuch/mime-node.c, branch 0.31_rc0

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

crypto: Make _notmuch_crypto_decrypt take a GMimeObject

2020-05-23T01:11:33Z

As we prepare to handle S/MIME-encrypted PKCS#7 EnvelopedData (which is not multipart), we don't want to be limited to passing only GMimeMultipartEncrypted MIME parts to _notmuch_crypto_decrypt. There is no functional change here, just a matter of adjusting how we pass arguments internally. 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

mime-node: Clean up unwrapped MIME parts correctly.

2020-03-23T01:21:03Z

Avoid a memory leak in the notmuch command line. gmime_multipart_encrypted_decrypt returns a GMimeObject marked by GMime as "transfer full", so we are supposed to clean up after it. When parsing a message, notmuch would leak one GMimeObject part per multipart/encrypted MIME layer. We clean it up by analogy with cleaning up the signature list associated with a MIME node. Signed-off-by: Daniel Kahn Gillmor

mime-node: rename decrypted_child to unwrapped_child

2020-03-23T01:20:52Z

When walking the MIME tree, we might need to extract a new MIME object. Thus far, we've only done it when decrypting multipart/encrypted messages, but PKCS#7 (RFC 8551, S/MIME) has several other transformations that warrant a comparable form of unwrapping. Make this member re-usable for PKCS#7 unwrappings as well as multipart/encrypted decryptions. This change is just a naming change, it has no effect on function. Signed-off-by: Daniel Kahn Gillmor

mime-node: Pass the correct flags to g_mime_multipart_signed_verify

2020-03-20T00:55:41Z

GMIME_ENCRYPT_NONE and GMIME_VERIFY_NONE have the same value, but they are different enumerated types. So in C, this is a cosmetic change, but it is technically correct if we only had stricter typing. Signed-off-by: Daniel Kahn Gillmor

cli/{show,reply}: use repaired form of "Mixed Up" mangled messages

2019-09-15T23:07:06Z

When showing or replying to a message that has been mangled in transit by an MTA in the "Mixed up" way, notmuch should instead use the repaired form of the message. Tracking the repaired GMimeObject for the lifetime of the mime_node so that it is cleaned up properly is probably the trickiest part of this patch, but the choices here are based on the idea that the mime_node_context is the memory manager for the whole mime_node tree in the first place, so new GMimeObject tree created on-the-fly during message parsing should be disposed of in the same place. 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

util/crypto: _n_m_crypto_potential_payload returns whether part is the payload

2019-09-01T11:38:11Z

Our _notmuch_message_crypto_potential_payload implementation could only return a failure if bad arguments were passed to it. It is an internal function, so if that happens it's an entirely internal bug for notmuch. It will be more useful for this function to return whether or not the part is in fact a cryptographic payload, so we dispense with the status return. If some future change suggests adding a status return back, there are only a handful of call sites, and no pressure to retain a stable API, so it could be changed easily. But for now, go with the simpler function. We will use this return value in future patches, to make different decisions based on whether a part is the cryptographic payload or not. But for now, we just leave the places where it gets invoked marked with (void) to show that the result is ignored. Signed-off-by: Daniel Kahn Gillmor

mime-node: split out _mime_node_set_up_part

2019-09-01T11:17:00Z

This is a code reorganization that should have no functional effect, but will make future changes simpler, because a future commit will reuse the _mime_node_set_up_part functionality without touching _mime_node_create. In the course of splitting out this function, I noticed a comment in the codebase that referred to an older name of _mime_node_create (message_part_create), where this functionality originally resided. I've fixed that comment to refer to the new function instead. Signed-off-by: Daniel Kahn Gillmor