David Bremner [Wed, 6 Dec 2017 01:17:58 +0000 (21:17 -0400)]
test/emacs: add exploit mitigation test
This test will pass if either the notmuch show mitigation code is
working correctly, or upstream emacs mime handling code has it's own
fix for https://bugs.gnu.org/28350.
Tomi Ollila [Wed, 6 Dec 2017 01:17:57 +0000 (21:17 -0400)]
emacs: letf enriched-decode-display-prop for text/enriched display
Dynamically bind enriched-decode-display-prop when inserting
text/enriched part. This complements commit 9b0582383833 for
emacs versions before 24.4 which do not have advice-add
functionality.
crypto: signature verification reports valid User IDs
When i'm trying to understand a message signature, i care that i know
who it came from (the "validity" of the identity associated with the
key), *not* whether i'm willing to accept the keyholder's other
identity assertions (the "trust" associated with the certificate).
We've been reporting User ID information based on the "trust"
associated with the certificate, because GMime didn't clearly expose
the validity of the User IDs.
This change relies on fixes made in GMime 3.0.3 and later which
include https://github.com/jstedfast/gmime/pull/18.
Jani Nikula [Mon, 16 Oct 2017 15:40:44 +0000 (18:40 +0300)]
cli/crypto: fix segfault on failed gmime2 crypto context creation
Commit 1fdc08d0ffab ("cli/crypto: treat failure to create a crypto
context as fatal.") started treating crypto context creation failures
"as fatal", returning NULL from _mime_node_create().
Unfortunately, we do not have NULL checks for _mime_node_create()
failures. The only caller, mime_node_child(), could check and return
NULL (as it's documented to do on errors) but none of the several call
sites have NULL checks either. And none of them really have a trivial
but feasible and graceful way of recovery.
So while the right thing to do would be to handle NULL returns
properly all over the place, and we have other scenarios that do
return NULL from above mentioned functions, the crypto context
creation failure is something that does seem to show up regularly in
some scenarios, revert back to the functionality before commit 1fdc08d0ffab as an interim fix.
Jani Nikula [Mon, 11 Sep 2017 20:09:49 +0000 (23:09 +0300)]
emacs: override enriched-decode-display-prop for text/enriched display
Switch to a local version of enriched-decode-display-prop if we
encounter a text/enriched part. This is to mitigate
https://bugs.gnu.org/28350. Normally it would be prudent to remove the
override afterwards, but in this case just leave it in.
Notes from db:
This doesn't disable text/enriched, just one feature of it.
David Bremner [Thu, 3 Aug 2017 13:20:37 +0000 (09:20 -0400)]
debian: add maintainer scripts to remove old startup file
We do it for notmuch and notmuch-emacs because the history is a bit
unclear. It seems to be safe to call when that conffile is not owned
by a given package
resolve lintian tag debhelper-but-no-misc-depends notmuch-emacs
This is likely not strictly necessary given that notmuch-emacs is a
transitional package. But having a simple consistency until we
eventually remove the transitional notmuch-emacs package seems ok too,
and fewer arbitrary lintian warnings will make real lintian warnings
more visible.
David Bremner [Mon, 17 Jul 2017 11:47:18 +0000 (08:47 -0300)]
util: make g_mime_utils_header_decode_date_unix match prototype
The problem shows up on 32 bit architectures where sizeof(time_t) !=
sizeof(gint64). Upcasting the 32 bit time_t to a 64 bit integer
should hopefully be safe.
David Bremner [Wed, 12 Jul 2017 10:48:18 +0000 (07:48 -0300)]
emacs: change default for notmuch-crypto-process-mime to t
There are some cases like remote usage where this might cause
problems, but those users can easily customize the variable. The
inconvenience seems to be outweighed by the security benefit for most
users.
config: deprecate/drop crypto.gpg_path under gmime 2.6/3.0
gmime 3.0 no longer offers a means to set the path for gpg.
Users can set $PATH anyway if they want to pick a
differently-installed gpg (e.g. /usr/local/bin/gpg), so this isn't
much of a reduction in functionality.
The one main difference is for people who have tried to use "gpg2" to
make use of gpg 2.1, but that isn't usefully co-installable anyway.
The reply-to munging code might behave differently whether there's an
exact match on the strings or not, or whether the string is a raw
addr-spec instead of an name-addr. These tests cover those variations
(i also had to tweak json output further below when this new test was
added).
David Bremner [Fri, 2 Jun 2017 23:57:01 +0000 (20:57 -0300)]
cli: make keyid from fingerprint in gmime 3.0
The "key_id" field seems to used for userid in gmime-3.0, while the
keyid is dropped in the fingerprint field if the full fingerprint is
not available.
We need to rewrite the loop for gmime-3.0; move the loop body to its
own function to avoid code duplication. Keep the common exit via
"goto DONE" to make this pure code movement. It's important to note
that the existing exit path only deallocates the iterator.
David Bremner [Sat, 1 Jul 2017 15:18:43 +0000 (12:18 -0300)]
cli/show: convert keyword options to booleans
There are two keyword options here that impliment boolean options. It
is simpler to use the built-in boolean argument handling, and also
more robust against divergence in parsing boolean and keyword arguments.