These tests were an attempt to establish that the content of the
"Legacy Display" part is the same as the actual protected headers of
the message. But this is more conservative than we need to be.
https://www.ietf.org/id/draft-autocrypt-lamps-protected-headers-02.html
section 5.3 makes clear that the Legacy Display part is purely
decorative, and section 5.2.1 clarifies that the detection can be done
purely by MIME structure and Content-Type alone.
Furthermore, now that we're accepting text/plain Legacy Display parts,
it's not clear the lines in the Legacy Display part should be
interpreted as needing an exact string match (e.g. "real" headers are
likely to be RFC 2047 encoded, but the text/plain Legacy Display part
probably should not be).
The concerns that motivated this test in the past were twofold: that
we might accidentally hide some information from the reader of the
message that they should have available to them, or that we could
introduce a covert channel that would be invisible to other clients.
I no longer think these are significant concerns:
a) There will be no accidental misidentification of a Legacy Display
part. The identification of the Legacy Display part is
unambiguous due to MIME structure and Content-Type. MIME
structure MUST be the first child part of a two-part
multipart/mixed Cryptographic Payload. And the
protected-headers=v1 content-type parameter must be present on
both the cryptographic payload and the legacy display part, so no
one would accidentally generate this structure and have it be
accidentally matched.
b) As for creating a covert channel, many such channels already
exist. For example, non-standard e-mail headers, custom MIME
types, unusual MIME structures, etc, all make it possible to ship
some content in a message that will be visible in some MUAs but
not in others. This doesn't make the situation demonstrably
worse.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
https://www.ietf.org/id/draft-autocrypt-lamps-protected-headers-02.html
Makes it clear that the "Legacy Display" part of an encrypted message
with protected headers can (and indeed, should) be of content-type
text/plain, though some clients still generate the Legacy Display part
as content-type text/rfc822-headers. Notmuch should recognize the
part whichever of the two content-types it uses.
See also discussion in
https://github.com/autocrypt/protected-headers/issues/23 for why the
community of implementers is moving in the direction of text/plain.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Another fix to the docstrings, this time for the English part of the
docstrings, not the Python class name. No functional changes here.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Rather than ship from the source directories, ship these files from
where they're installed by "make install".
This doesn't resolve all the dh_missing warnings yet (due to #946142),
but it leaves the last bit of that problem in the hands of the dh-elpa
package, and it's not due to notmuch's packaging any longer.
Note that notmuch-pkg.el is only relevant for elpa, so it was not
installed by "make install", and has to be extracted deliberately from
the source tree.
Note also that we now don't ship make-deps.el or rstdoc.el, as these
are build tools and don't belong in the deployed package.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
This was being shipped by "make install", but we weren't shipping it
in the debian package. Thanks to dh_missing for noticing!
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
This commit changes the behaviour of notmuch-mua-attachment-check
so that it stops searching for notmuch-mua-attachment-regexp when a
new mime-part is reached. This avoids false warnings when matching
words occur inside forwarded messages.
Rather than blocking emacs while gpg does its' thing, by default run
key retrieval asynchronously, possibly updating the display of the
message on successful completion.
In case zlib not found by pkg-config(1) the pkg-config information
is resolved by attempting to print ZLIB_VERSION from from zlib
installation if it exists anyway.
If above done successfully compat/zlib.pc is written for forthcoming
pkg-config execution.
Since `set -u` is in effect (since 124a67e96, 2016-05-06),
expanding unset $PKG_CONFIG_PATH (would have) failed whenever tried.
Now it is changed to set as "$PKG_CONFIG_PATH:compat" if PKG_CONFIG_PATH
is set and is non-empty string, plain "compat" otherwise.
Zsh searches in the $fpath array for completion functions. By default
this includes $(prefix)/share/zsh/site-functions but not the existing
value. The prefix for zsh and notmuch isn't guaranteed to be the same
but it normally will be making this a better default for
zsh_completion_dir.
I was supposed to amend the original patch that added this function,
but somehow I botched that. The original version runs, so make an
extra commit for the tidying.
This moves away from the deprecated notmuch_database_add_message API
and instead uses the notmuch_database_index_file API. This means
instroducing a class to manage the index options and bumping the
library version requirement to 5.1.
This add the notmuch version and absolute path of the binary used
in the pytest header. This is nice when running the tests
interactively as you get confirmation you're testing the version you
thought you were testing.
The entire python-cffi test suite is considered as a single test at
the level of the notmuch test suite. This might or might not be ideal,
but it gets them run.
This introduces CFFI-based Python3-only bindings.
The bindings aim at:
- Better performance on pypy
- Easier to use Python-C interface
- More "pythonic"
- The API should not allow invalid operations
- Use native object protocol where possible
- Memory safety; whatever you do from python, it should not coredump.
This is an unbound function that is quite useful. It opens a selected
thread in notmuch-tree from the current search query.
Signed-off-by: William Casarin <jb55@jb55.com>
Fixed: If the output file for a dump was non-writeable, gzclose_w()
was called twice on the output file handle, resulting in SIGABRT.
(cherry picked from commit 17806ecc95)
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.
