notmuch/test/corpora, branch 0.38

lib: index attachments with mime types matching index.as_text

2023-04-02T22:24:43Z

Instead of skipping indexing all attachments, we check of a (user configured) mime type that is indexable as text.

test: replace aging OpenPGP key used in the test suite

2022-09-23T23:16:00Z

This replaces the old OpenPGPv4 key that is used in the test suite with a more modern OpenPGPv4 key. All cryptographic artifacts in the test suite are updated accordingly. Having old cryptographic artifacts in the test suite presents a problem once the old algorithms are rejected by contemporary implementations. For reference, this is the old key. sec rsa1024 2011-02-05 [SC] 5AEAB11F5E33DCE875DDB75B6D92612D94E46381 uid [ unknown] Notmuch Test Suite (INSECURE!) ssb rsa1024 2011-02-05 [E] And this is the new key. Note that is has the same shape, but uses Ed25519 and Cv25519 instead of 1024-bit RSA. sec ed25519 2022-09-07 [SC] 9A3AFE6C60065A148FD4B58A7E6ABE924645CC60 uid [ultimate] Notmuch Test Suite (INSECURE!) ssb cv25519 2022-09-07 [E]

test: add known broken test for indexing text/* attachments

2022-09-03T12:06:08Z

The general problem of indexing attachments requires some help to turn things into text, but (most?) text/* should be doable internally, possibly with optimizations as for the text/html case.

test: rename indexing corpus

2022-09-03T12:05:44Z

The corpus is not really suitable for general indexing test since the sole message is ignored (and will most likely continue to be ignored) by notmuch-new.

test: add new corpus of duplicate messages

2022-07-05T10:05:49Z

This corpus will be used to test a new --duplicate option for notmuch-show

test: make T450 independent of application/octet-stream interpretation

2022-05-29T10:23:32Z

The actual content type of `application/octet-stream` is up to content type detection of the reader, and thus may not be stable across implementations or versions. This showed up when fd46fc19 ("emacs: document/defcustom notmuch-multipart/alternative-discouraged", 2022-05-14) introduced a test for omitting a part of type `text/html` because it expected a part of type `application/octet-stream` to remain in place, i.e. a part of "unstable type". In particular, tests with `fd46fc19` would succeed on RHEL/EPEL but fail on all current Fedoras with ``` FAIL multipart/alternative hides html by default --- T450-emacs-show.16.notmuch-show-multipart-alternative 2022-05-26 15:34:42.100557244 +0000 +++ T450-emacs-show.16.OUTPUT 2022-05-26 15:34:42.102557207 +0000 @@ -24,7 +24,7 @@ uses 64 as the buffer size. [ text/html (hidden) ] -[ 0001-Deal-with-situation-where-sysconf-_SC_GETPW_R_SIZE_M.patch: application/octet-stream (as text/x-diff) ] +[ 0001-Deal-with-situation-where-sysconf-_SC_GETPW_R_SIZE_M.patch: application/octet-stream (as text/x-patch) ] From e3bc4bbd7b9d0d086816ab5f8f2d6ffea1dd3ea4 Mon Sep 17 00:00:00 2001 From: Alexander Botero-Lowry Date: Tue, 17 Nov 2009 11:30:39 -0800 ``` due to the different type detected. Fix this by giving that message a specicific type of `text/x-diff` in the test corpus, and adjust all affected test outputs. Signed-off-by: Michael J Gruber Amended-by: db, fix some trailing whitespace

test: start corpus for attachments

2022-05-16T10:10:12Z

Initially these are to test the emacs frontend.

test: start new corpus of test messages for indexing code

2022-02-20T00:14:18Z

This particular message is not recognized by notmuch as mail, but is fine according to e.g. mutt. The trigger for this bad behaviour seems to be a second "From " ocurring at the beginning of the line but inside an attachment.

test/crypto: test message with rfc822 attachment.

2021-08-30T23:24:59Z

This is intended to help track down a display problem in the emacs front end

tests/smime: add tests for S/MIME SignedData

2020-04-30T20:57:26Z

Add a simple S/MIME SignedData message, taken from an upcoming draft of https://datatracker.ietf.org/doc/draft-autocrypt-lamps-protected-headers/ RFC 8551 describes a SignedData, a one-part clearsigned object that is more resistant to common patterns of MTA message munging than multipart/signed (but has the downside that it is only readable by clients that implement S/MIME). To make sure sure notmuch can handle this kind of object, we want to know a few things: Already working: - Is the content of the SignedData object indexed? It actually is right now because of dumb luck -- i think we're indexing the raw CMS object and it happens to contain the cleartext of the message in a way that we can consume it before passing it on to Xapian. - Are we accidentally indexing the embedded PKCS#7 certificates? We don't want to, and for some reason I don't understand, our indexing is actually skipping the embedded certificates already. That's good! Still need fixing: - do we know the MIME type of the embedded part? - do we know that the message is signed? - can notmuch-show read its content? - can notmuch-show indicate the signature validity? - can notmuch-reply properly quote and attribute content? Signed-off-by: Daniel Kahn Gillmor