notmuch/lib, branch debian/0.30_rc0-1

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

lib: replace STRNCMP_LITERAL in __message_remove_indexed_terms

2020-05-04T13:55:43Z

strncmp looks for a prefix that matches, which is very much not what we want here. This fixes the bug reported by Franz Fellner in id:1588595993-ner-8.651@TPL520

build: drop support for xapian versions less than 1.4

2020-04-24T00:28:45Z

Xapian 1.4 is over 3 years old now (1.4.0 released 2016-06-24), and 1.2 has been deprecated in Notmuch version 0.27 (2018-06-13). Xapian 1.4 supports compaction, field processors and retry locking; conditionals checking compaction and field processors were removed but user may want to disable retry locking at configure time so it is kept.

Correct doxygen framing for libnotmuch.h

2020-03-20T00:56:05Z

Apparently doxygen needs its comments formatted in a specific way to notice that the group is closed. Without this fix, with doxygen 1.8.16-2 we see: ``` doxygen ./doc/doxygen.cfg …/notmuch/lib/notmuch.h:2322: warning: end of file while inside a group ``` Signed-off-by: Daniel Kahn Gillmor

Merge tag 'debian/0.29.3-1'

2019-11-27T12:45:43Z

notmuch release 0.29.3-1 for unstable (sid) [dgit] [dgit distro=debian no-split --quilt=linear]

lib: fix memory error in notmuch_config_list_value

2019-11-27T11:58:09Z

The documentation for notmuch_config_list_key warns that that the returned value will be destroyed by the next call to notmuch_config_list_key, but it neglected to mention that calling notmuch_config_list_value would also destroy it (by calling notmuch_config_list_key). This is surprising, and caused a use after free bug in _setup_user_query_fields (first noticed by an OpenBSD porter, so kudos to the OpenBSD malloc implementation). This change fixes that use-after-free bug.

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