Previous version expected full upstream install to be run, and also
caused lintian whine about the the desktop file being in a different
package than the script. I'm not sure they shouldn't both be in
elpa-notmuch, but I can see how they should be together.
It seems our previous attempt with order-only targets was not
sufficient to avoid problems with sphinx-builds doctree cache [0].
Looking around at other people's approaches [1], using separate
doctrees was suggested. I guess there might be a slight loss of
efficiency, but it seems more robust.
[0]: build failures were first noticed in Debian experimental, but I was able to duplicate it in
my usual build environment about 1 in 8 builds.
[1]: in particular
9e3fc1657d
Part 0 of a multipart/encrypted object is
GMIME_MULTIPART_ENCRYPTED_VERSION; part 1 is
GMIME_MULTIPART_ENCRYPTED_CONTENT. Using the name for what we want
describes our intent more clearly than using a magic number in the
code.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Protected subject lines were being emitted in reply when the cleartext
of documents was indexed. create_reply_message() was pulling the
subject line from the index, rather than pulling it from the
GMimeMessage object that it already has on hand.
This one-line fix to notmuch-reply.c solves that problem, and doesn't
cause any additional tests to fail.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
These tests are currently broken! When a protected subject is indexed
in the clear, it leaks in the reply headers :(
For emacs, we set up separate tests for when the protected header is
indexed in the clear and when it is unindexed. neither case should
leak, but the former wasn't tested yet.
We will fix the two broken tests in a subsequent patch.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
This tests notmuch-show; headers appear appropriately based on the
setting of notmuch-crypto-process-mime.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
We initially test only notmuch-search; tests for other functionality
come in different patchsets later.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
We want to make sure that internally-forwarded messages don't end up
"bubbling up" when they aren't actually the cryptographic payload.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
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>
When walking the MIME tree, if we discover that we are at the
cryptographic payload, then we would like to record at least the
Subject header of the current MIME part.
In the future, we might want to record many other headers as well, but
for now we will stick with just the Subject.
See
https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html#cryptographic-envelope
for more description of the Cryptographic Payload vs. the
Cryptographic Envelope.
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
Deliberately populate the message's cryptographic status while walking
the MIME tree from the CLI.
Note that the additional numchild argument added to _mime_node_create
is a passthrough needed to be able to adequately populate the crypto
state object.
The mime node context (a per-message context) gains a cryptographic
status object, and the mime_node_t object itself can return a view on
that status to an interested party.
The status is not yet populated, and for now we can keep that view
read-only, so that it can only be populated/modified during MIME tree
traversal.
E-mail encryption and signatures reported by notmuch are at the MIME
part level. This makes sense in the dirty details, but for users we
need to have a per-message conception of the cryptographic state of
the e-mail. (see
https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html for more
discussion of why this is important).
The object created in this patch is a useful for tracking the
cryptographic state of the underlying message as a whole, based on a
depth-first search of the message's MIME structure.
This object stores a signature list of the message, but we don't
handle it yet. Further patches in this series will make use of the
signature list.
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>
This should not change the indexing process yet as nothing calls
_notmuch_message_gen_terms with a user prefix name. On the other hand,
it should not break anything either.
_notmuch_database_prefix does a linear walk of the list of (built-in)
prefixes, followed by a logarithmic time search of the list of user
prefixes. The latter is probably not really noticable.
This will be used to avoid needing a database access to resolve a db
prefix from the corresponding UI prefix (e.g. when indexing). Arguably
the setup of the separate header map does not belong here, since it is
about indexing rather than querying, but we currently don't have any
other indexing setup to do.
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.
