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.
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.
When compiling as C code (instead of C++) against gmime 3.0, gcc gives
errors like the following:
error: invalid conversion from ‘int’ to ‘GMimeDecryptFlags’ [-fpermissive]
so use explicit *_NONE values instead.
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.
It turns out that our use of GMimeStreamPipe has only succeeded
because gmime has been ignoring some seek failures; this will no
longer be the case in gmime 3.0, so we use a GMimeStreamPipe, which
does not assume seekability, wrapped in a buffering stream.
Apparently some systems (MacOS?) have a system library called libutil
and the name conflict causes problems. Since this library is quite
notmuch specific, rename it to something less generic.
With the removal of the embedded libsha1, we lost the first and last
user of the platform byte order checks. Remove them from configure,
and remove the endian util header.
Many of the external links found in the notmuch source can be resolved
using https instead of http. This changeset addresses as many as i
could find, without touching the e-mail corpus or expected outputs
found in tests.
Because of limitations in the C type system, we can't a strtok_len
that can work on both const string and non-const strings. The C
library solves this by taking a const char* and returning a char*
in functions like this (e.g., strchr), but that's not const-safe.
Solve it by introducing strtok_len_c, a version of strtok_len for
const strings.
The idea is to provide a more or less drop in replacement for readline
to read from zlib/gzip streams. Take the opportunity to replace
malloc with talloc.
Previously, make_boolean_term did not quote empty boolean terms or
boolean terms that started with '('. These cases are incompatible
with Xapian: empty terms cannot be omitted, and boolean terms that
start with '(' trigger an alternate term quoting syntax.
Fix this by quoting empty terms and terms that contain '('.
Unfortunately old versions of GCC and clang do not provide byte order
macros, so we re-invent them.
If UTIL_BYTE_ORDER is not defined or defined to 0, we fall back to
macros supported by recent versions of GCC and clang
This parses the subset of Xapian's boolean term quoting rules that are
used by make_boolean_term. This is provided as a generic string
utility, but will be used shortly in notmuch restore to parse and
optimize for ID queries.
This is now a generic boolean term quoting function. It performs
minimal quoting to produce user-friendly queries.
This could live in tag-util as well, but it is really nothing specific
to tags (although the conventions are specific to Xapian).
The API is changed from "caller-allocates" to "readline-like". The
scan for max tag length is pushed down into the quoting routine.
Furthermore, this now combines the term prefix with the quoted term;
arguably this is just as easy to do in the caller, but this will
nicely parallel the boolean term parsing function to be introduced
shortly.
This is an amalgamation of code written by David Bremner and myself.
This is to give a home to strtok_len. It's a bit silly to add a header
for one routine, but it needs to be shared between several compilation
units (or at least that's the most natural design).
Annotating functions that do not return with the noreturn attribute
(which is understood by both gcc and clang) prevents static analyzers
from generating false positives (internal_error is used to terminate
the process and is used extensively in error handling code paths).
Remove the return statement that was placed there to appease the
compiler. Functions annotated with noreturn are not supposed to return
any values.
Signed-off-by: Justus Winter <4winter@informatik.uni-hamburg.de>
libnotmuch.so.* linking fail on some environments. According to
David Bremner on irc:
"We jump through hoops with the linker script (notmuch.sym) so
the pragmas are not needed. And they are a little bizarre in a
library anyway..."
This pushes the error handling up one step, but makes the function
more flexible. Running out of memory still triggers an internal error,
in the spirit of other xutils functions.
We keep the lib/xutil.c version. As a consequence, also factor out
_internal_error and associated macros. It might be overkill to make a
new file error_util.c for this, but _internal_error does not really
belong in database.cc.
