notmuch/lib/index.cc, branch 0.32_rc0

lib: run uncrustify

2021-03-13T12:45:34Z

This is the result of running $ uncrustify --replace --config ../devel/uncrustify.cfg *.c *.h *.cc in the lib directory

smime: Index cleartext of envelopedData when requested

2020-05-23T01:12:00Z

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

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

index: repair "Mixed Up" messages before indexing.

2019-09-15T23:07:06Z

When encountering a message that has been mangled in the "mixed up" way by an intermediate MTA, notmuch should instead repair it and index the repaired form. When it does this, it also associates the index.repaired=mixedup property with the message. If a problem is found with this repair process, or an improved repair process is proposed later, this should make it easy for people to reindex the relevant message. The property will also hopefully make it easier to diagnose this particular problem in the future. 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

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

lib: run uncrustify

2019-06-14T10:41:27Z

This is the result of running $ uncrustify --replace --config ../devel/uncrustify.cfg *.c *.h *.cc in the lib directory

indexing: record protected subject when indexing cleartext

2019-05-29T11:14:44Z

When indexing the cleartext of an encrypted message, record any protected subject in the database, which should make it findable and visible in search. Signed-off-by: Daniel Kahn Gillmor