| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit d487ef9e58bcd193118f19f771d5ef3984616be5
Author: Jani Nikula <jani@nikula.org>
Date: Sat Mar 30 15:53:16 2013 +0200
cli: mime node: abstract decryption and signature verification
introduced a compiler warning, reported by Mark Walters, when building
against gmime 2.4:
mime-node.c:224:9: warning: assignment discards ‘const’ qualifier from
pointer target type [enabled by default]
Pass the non-const signature validity to the destructor to fix this.
|
| |
|
|
|
|
|
|
|
| |
The code filled with #ifdef GMIME_ATLEAST_26 is difficult to
read. Abstract the decryption and signature verification into
functions, with separate implementations for GMime 2.4 and 2.6, to
clarify the code.
There should be no functional changes.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
GMIME_IS_MULTIPART and GMIME_IS_MESSAGE both handle NULL pointers
gracefully, but the G_OBJECT_TYPE used in the error handling block
dereferences it without checking it first.
Fix this by checking whether parent->part is valid.
Found using the clang static analyzer.
Signed-off-by: Justus Winter <4winter@informatik.uni-hamburg.de>
|
| |
|
|
|
|
|
|
| |
This has the affect of lazily creating the crypto contexts only when
needed. This removes code duplication from notmuch-show and
notmuch-reply, and should speed up these functions considerably if the
crypto flags are provided but the messages don't have any
cryptographic parts.
|
| |
|
|
|
|
|
| |
Use this flag rather than depend on the existence of an initialized
gpgctx, to determine whether we should verify a multipart/signed. We
will be moving to create the ctx lazily, so we don't want to depend on
it being previously initialized if it's not needed.
|
| |
|
|
| |
This simplifies some more interfaces.
|
| |
|
|
| |
This simplifies the interface considerably.
|
| |
|
|
|
|
| |
gmime 2.4 defines GMimeCipherContext, while 2.6 defines
GMimeCryptoContext. typedef them both to notmuch_crypto_context_t to
cover this discrepancy and remove a bunch of #ifdefs.
|
| | |
|
| |
|
|
|
|
|
| |
This makes the part numbers readily accessible to formatters.
Hierarchical part numbering would be a more natural and efficient fit
for MIME and may be the way to go in the future, but depth-first
numbering maintains compatibility with what we currently do.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are lots of API changes in gmime 2.6 crypto handling. By adding
preprocessor directives, it is however possible to add gmime 2.6 compatibility
while preserving compatibility with gmime 2.4 too.
This is mostly based on id:"8762i8hrb9.fsf@bookbinder.fernseed.info".
This was tested against both gmime 2.6.4 and 2.4.31. With gmime 2.4.31, the
crypto tests all work fine (as expected). With gmime 2.6.4, one crypto test is
currently broken (signature verification with signer key unavailable), most
likely because of a bug in gmime which will hopefully be fixed in a future
version.
|
| |
|
|
|
|
|
| |
This function matches how we number parts for the --part argument to
show. It will allow us to jump directly to the desired part, rather
than traversing the entire tree and carefully tracking whether or not
we're "in the zone".
|
|
|
This wraps all of the complex MIME part handling in a single, simple
function that gets part N from *any* MIME object, so traversing a MIME
part tree becomes a two-line for loop. Furthermore, the MIME node
structure provides easy access to envelopes for message parts as well
as cryptographic information.
This code is directly derived from the current show_message_body code
(much of it is identical), but the control relation is inverted:
instead of show_message_body controlling the traversal of the MIME
structure and invoking callbacks, the caller controls the traversal of
the MIME structure.
|
Jani Nikula
Justus Winter
Jameson Graef Rollins
Austin Clements
Thomas Jost