| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
based on the same patch from dkg as the previous commit.
|
|
gmime 3.0 knows how to select the correct GMimeCryptoContext
automatically, so a bunch of the code in notmuch can be dropped in
that case.
The #ifdef removal of the crypto stuff is better than #define aliasing
in gmime-extra.h for this stuff. When built against gmime 3.0:
* it reduces compiled code, and
* it avoids initializing unused gpgme contexts
(based on a patch from dkg)
|
|
These are due to (excessively?) fancy macro definitions in gmime-extra.h
|
|
Silently ignoring signed/encrypted parts seems like the wrong idea,
and it also complicates future gmime-3.0 compatibility changes.
|
|
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.
|
|
- removed 7 trailing dots -- to make those lines subsection headers
- converted some (mime type) text to monospace
- removed one extra space
|
|
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.
|
|
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).
|
|
In some (bad!) cases, "notmuch reply" might fail, or might even
segfault. If this happens, it indicates a bug, and the test suite
should notice it.
|
|
Apparently it moved from "name" to "key_id" 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.
|
|
In gmime 3.0 this function is "transfer none", so no deallocation is
needed (or permitted)
|
|
The iterator is gone, so we need a new loop structure.
|
|
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.
|
|
This changes return type in gmime 3.0
|
|
Both the enum and the values are renamed in GMime 3.0.
|
|
The ERROR enum is merged into to the STATUS enum, and the set of flags
is different.
|
|
Several functions have added arguments which accept NULL and provide
hopefully sensible defaults. Use macros to minimize source changes.
|
|
This function, and associated enum, have been renamed and generalized
in gmime-3.0.
|
|
This function changes semantics in gmime-3.0 so make a new function
that provides the same functionality in both
|
|
This function changes signature in gmime 3.0, so we provide two new
functions, one for each signature.
|
|
This function goes away in gmime-3.0. Also, the memory management is
apparently error prone, witness the memory leak in notmuch-reply.
|
|
I can't see the space in the output of gpg -K --with-colons
|
|
Defer the complication of optional boolean arguments for later (never?).
|
|
The idea is to allow it (in a future commit) advance to the next argv
element to get a value
|
|
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.
|
|
|
|
notmuch-dbgsym should be auto generated now.
|
|
Have an empty list of signatures is not the nicest mechanism to signal
complete failure to verify, but it's the one we currently have.
|
|
This is a good thing to test in any case, but particularly as we hit
the dark corners of the gmime crypto API.
|
|
Currently I'm not sure what the intent of this test is, so it's not
clear if the new answer is better or worse than the old one.
|
|
The output of headers here reflects an underlying bug / quirk of
gmime-2.6.
|
|
We want to have the bodies of the multipart available in a file on
their own for planned modifications to tests.
|
|
Since the error field is unused by the emacs front end, no changes are
needed other than bumping the format version number.
As it is, this is a bit overengineered, but it will reduce duplication
when we support gmime 3.0
|
|
Replace numeric errors with human readable flags. Not all sig_error
keys will necessarily be generated with a given version of gmime.
Drop status "none" as it's currrently unused and I don't know what
it's for.
|
|
Keeping the emacs interface running old format-versions makes it
impossible to test new format-versions or deprecate old ones.
|
|
|
|
Just a no-change rebuild.
|
|
merge in changes from 0.23.7-3 debian upload
|
|
The filter just drops all (HTML) tags. As an enabling change, pass the
content type to the filter constructor so we can decide which scanner
to user.
|
|
To match things more complicated than fixed strings, we need states
with multiple out arrows.
|
|
We want to reuse the scanner definition with a different table. This
is mainly code movement, and making the state table part of the filter
struct/class.
|
