This test scans for all the possible protected headers (including
bogus/broken ones) that are present in the protected-headers corpus,
trying to make sure that only the ones that are not broken or
malformed show up in a search after re-indexing.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Up to this point, we've tested protected headers on messages that have
either been encrypted or signed, but not both.
This adds a couple tests of signed+encrypted messages, one where the
subject line is masked (outside subject line is "Subject Unavailable")
and another where it is not (outside Subject: matches inner Subject:)
See the discussion at
https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html#protected-headers
for more details about the nuances between signed, stripped, and
stubbed headers.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
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 <dkg@fifthhorseman.net>
Now that we can decrypt headers, we want to make sure that clients
using "notmuch reply" to prepare a reply don't leak cleartext in their
subject lines. In particular, the ["reply-headers"]["Subject"] should
by default show the external Subject.
A replying MUA that intends to protect the Subject line should show
the user the Subject from ["original"]["headers"]["Subject"] instead
of using ["reply-headers"]["Subject"].
This minor asymmetry with "notmuch show" is intentional. While both
tools always render the cleartext subject line when they know it (in
["headers"]["Subject"] for "notmuch show" and in
["original"]["headers"]["Subject"] for "notmuch reply"), "notmuch
reply" should never leak something that should stay under encrypted
cover in "reply-headers".
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Make sure that we emit the correct cryptographic envelope status for
cleartext signed messages.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Adding another test to ensure that we handle protected headers
gracefully when no external subject is present.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
The header-mask member of the per-message crypto object allows a
clever UI frontend to mark whether a header was protected (or not).
And if it was protected, it contains enough information to show useful
detail to an interested user. For example, an MUA could offer a "show
what this message's Subject looked like on the wire" feature in expert
mode.
As before, we only handle Subject for now, but we might be able to
handle other headers in the future.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Amended by db: tweaked schemata notation.
Correctly fix the two outstanding tests so that the protected (hidden)
subject is properly reported.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Here we add several variant e-mail messages, some of which have
correctly-structured protected headers, and some of which do not. The
goal of the tests is to ensure that the right protected subjects get
reported.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
This makes it easier to write fairly compact, readable tests of json
output, without needing to sanitize away parts that we don't care
about.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
This paves the way for emitting protected headers after verification
and decryption, because it means that the headers will only be emitted
after the body has been parsed.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
In certain cases of test suite failure, the summary report was not
being printed. In particular, any failure on the parallel test suite,
and any aborted test in the serialized test suite would end up hiding
the summary.
It's better to always show the summary where we can (while preserving
the return code). If we do abort due to this high-level failure,
though, we should also announce to the user that we're doing so as
close to the end of the process as possible, to make it easier to find
the problem.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
This allows MUAs that don't want to think about per-mime-part
cryptographic status to have a simple high-level overview of the
message's cryptographic state.
Sensibly structured encrypted and/or signed messages will work fine
with this. The only requirement for the simplest encryption + signing
is that the message have all of its encryption and signing protection
(the "cryptographic envelope") in a contiguous set of MIME layers at
the very outside of the message itself.
This is because messages with some subparts signed or encrypted, but
with other subparts with no cryptographic protection is very difficult
to reason about, and even harder for the user to make sense of or work
with.
For further characterization of the Cryptographic Envelope and some of
the usability tradeoffs, see here:
https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html#cryptographic-envelope
When we have not been able to evaluate the signature status of a given
MIME part, showing a content-free (and interaction-free) "[ Unknown
signature status ]" button doesn't really help the user at all, and
takes up valuable screen real-estate.
A visual reminder that a given message is *not* signed isn't helpful
unless it is always present, in which case we'd want to see "[ Unknown
signature status ]" buttons on all messages, even ones that don't have
a signing structure, but i don't think we want that.
Amended by db to drop the unused initialization of 'label'
To aid in diagnosing test suite tooling that interacts poorly with
coreutils' timeout, it's handy to be able to bypass it entirely.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
These restrictions are meant to prevent incompatibilities with the
Xapian query parser (which will split at non-word characters) and
clashes with future notmuch builtin fields.
We don't do anything with this configuration information information
yet, but nonetheless add a couple of regression tests to make sure we
don't break standard functionality when we do use the configuration
information.
Done via $COLORS_WITHOUT_TTY environment variable as passing options
to commands through parallel(1) does not look trivial.
Reorganized color checking in test-lib.sh a bit for this (perhaps
were not fully necessary but rest still an improvement):
- color checking commands in subshell are not run before arg parsing
(args may disable colors with --no-color)
- [ -t 1 ] is checked before forking subshell
Added initialization and checking of smtp_dummy_port
like it was done with smtp_dummy_pid.
Made those function-local variables.
One 8 spaces to tab consistency conversion.
And last, but definitely not least; while doing above
noticed that there were quite a few double-quoted strings
where $@ was in the middle of it -- replaced those with $*
for robustness ("...$@..." expands params to separate words,
"...$*..." params expands to single word).
Without this stdin may be anything that parent process provided for it.
Test processes might have tried to read something from it, which would
have caused undeterministic behavior.
E.g. gdb(1) tries to do tty related ioctls on fd 0 (and fd 1 and fd 2,
but those are redirected to 'test.output' before test runs).
To the best of my understanding, this original behaviour was what
Carl's homebrew parser produced. With commit 86f89385 Austin switched
to using GMime (2.6). This produced arguably worse results, but since
the input was bad, we could live with it. Now with GMime 3.0 we are
getting the original results again, and there is no reason to consider
this test broken.
When a parallel build fails (or when it times out, if timeout is
present), the test suite should not blithely succeed. Catch these
failures and at least report them.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
The current 2 minute timeout is reasonable, but to exercise the test
suite or induce timeout failures, we might want to make it shorter.
This makes it configurable so you can run (for example):
make check NOTMUCH_TEST_TIMEOUT=10s
We stick with the default of 2m.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
FINGERPRINT is already exported by add_gnupg_home, so this is
unnecessary. This change also happens to get rid of the superfluous
check-trustdb spew from the test suite that looked like this:
gpg: checking the trustdb
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
We did not have a test showing what message decryption looks like
within notmuch-emacs. This change gives us a baseline for future work
on the notmuch-emacs interface.
This differs from previous revisions of this patch in that it should
be insensitive to the order in which the local filesystem readdir()s
the underlying maildir.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
If either the moreutils or GNU parallel utility are available, run all
tests in parallel. On my eight core machine this makes for a ~x7
speed-up in the full test suite (1m24s -> 12s).
The design of the test suite makes this parallelization trivial.
The add_email_corpus test utility includes logic that tries to re-use
an index of the corpus if available. This was seemingly done as an
optimization, so that every test that uses the corpus didn't have to
create it's own index of the corpus. However, this has the perverse
side effect of entangling tests together, and breaks parallelization.
Forcing each test to do it's own index does increase the overall time
of the test slightly (~6%), but this will be more than made up for in
the next patch that introduces paraellization.
The typical use case for gpg is that if you control a secret key, you
mark it with "ultimate" ownertrust.
The opaque --import-ownertrust mechanism is GnuPG's standard mechanism
to set up ultimate ownertrust (the ":6:" means "ultimate", for
whatever reason).
We adjust the test suite to match this change, inverting the sense of
one test: since the default is now that the user ID of the suite's own
key is valid, we change the test to make sure that the user ID is not
emitted when it is *not* valid.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
The user ID on the self-test is a little bit clunky-looking. It also
may end up showing up elsewhere in the test suite. Centralizing the
user ID in one place should make it easier to handle if it ever
changes, and should make tests easier to read.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
This is a subtle difference, but the output of notmuch shouldn't ever
change based on ownertrust itself -- notmuch is intended to show valid
User IDs, and to avoid showing invalid User IDs.
It so happens that setting ownertrust of a key to ultimate sets all
associated user IDs to "full" validity, so the test is correct, but
just misnamed.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Previously if the input was exactly a multiple of the internal buffer
size, notmuch would attempt to fwrite nothing to stdout, but still
expected fwrite to return 1, causing a failure that looked like this:
$ notmuch show --format=raw id:87o96f1cya.fsf@codeaurora.org
...entire message shown as expected..
Error: Write failed
$ echo $?
1
To fix the problem don't call fwrite at all when there's nothing to
write.
Amended by db: add some tests of message sizes likely to cause this
problem.
This drops "file" from mime_node_context and just uses a local
variable. It also uses the new gzip aware utility routines recently
added to util/gmime-extra.c. The use of gzopen / gzfile in addition is
a bit icky, but the choice is between that, and providing yet another
readline implimentation that understands GMime streams.
Rather than storing the lower level stdio FILE object, we store a
GMime stream. This allows both transparent decompression, and passing
the stream into GMime for parsing. As a side effect, we can let GMime
close the underlying OS stream (indeed, that stream isn't visible here
anymore).
This change is enough to get notmuch-{new,search} working, but there is still
some work required for notmuch-show, to be done in a following commit.
note that "notmuch-show for message with invalid From" is still broken
in T310-emacs.sh. It would be good to debug what's going on there and
try to get it fixed!
signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Note that we do keep ignoring the gpg_path configuration option,
though, to avoid breakage of existing installations. It is ignored
like any other unknown configuration option, but we at least document
that it is ignored so that people who find it in their legacy configs
can know that it's safe to drop.
signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Unsigned encrypted mail shows up with a weird empty signature list.
If we successfully decrypted and there was no signature in it, we
should just not show a sigstatus at all.
The documentation for g_mime_decrypt_result_get_signatures says:
a GMimeSignatureList or NULL if the stream was not signed.
If a test has added a GnuPG homedir, it may well want to know the
fingerprint. This saves us from having to redefine this magic string
in multiple places when more tests eventually use the GnuPG homedir.
The new `body:` field (in Xapian terms) or prefix (in slightly
sloppier notmuch) terms allows matching terms that occur only in the
body.
Unprefixed query terms should continue to match anywhere (header or
body) in the message.
This follows a suggestion of Olly Betts to use the facility (since
Xapian 1.0.4) to add the same field with multiple prefixes. The double
indexing of previous versions is thus replaced with a query time
expension of unprefixed query terms to the various prefixed
equivalent.
Reindexing will be needed for 'body:' searches to work correctly;
otherwise they will also match messages where the term occur in
headers (demonstrated by the new tests in T530-upgrade.sh)
Add test of forwarding messages from within emacs.
The first test checks that a references header is properly
added to the new message. The second test checks that the
send-hook of the forwarding message adds a forwarded-tag
to the original message.
