The notmuch_crypto_t struct isn't used externally, and we have no
plans to explicitly export it. Prefix its name (and associated
functions) with _ to make that intent clear.
C99 stdbool turned 18 this year. There really is no reason to use our
own, except in the library interface for backward
compatibility. Convert the cli and test binaries to stdbool.
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)
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.
notmuch-show --verify will now also process S/MIME multiparts if
encountered. Requires gmime-2.6 and gpgsm.
Based on work by Jameson Graef Rollins <jrollins@finestructure.net>.
It's becoming a maintenance burden to do anything things with the
crypto glue code twice, once for 2.4 and once for 2.6. I don't have
any 2.4 version available to test on my development machine anymore,
so the 2.4 specific code paths are likely not very well tested.
GMIME takes a path to gpg, but we hardcode that path. In this commit
we set up argument passing and option storage to allow this path to
specified in the top level notmuch command.
Badly formed messages that don't specify a protocol in
signed/encrypted parts, end up with a protocol of NULL. strcasecmp in
notmuch_crypto_get_context then segfaults when trying to check it
against known protocols. If the protocol is NULL, just return an
empty context immediately (with appropriate message.)
The code filled with #ifdef GMIME_ATLEAST_26 is difficult to
read. Abstract gpg context creation into a function, with separate
implementations for GMime 2.4 and 2.6, to clarify the code.
There should be no functional changes.
For decryption, we expect there to be a functioning gpg-agent, and we
want gpg to talk to it for any needed credentials. There's a gmime
function to declare that: g_mime_gpg_context_set_use_agent() [1], [2].
Start using it.
I had gpg-agent running, but gpg "use-agent" configuration option
disabled. This resulted in an error message from 'notmuch show':
Failed to decrypt part: Canceled.
and json had this:
"encstatus" : [ { "status" : "bad" } ]
One could argue the "use-agent" option should be enabled, but I'd like
to use the agent only as a last resort. I think that's irrelevant
though. There's a gmime function to declare what we expect, so we
should use it. Conveniently it also fixes the problem in a user
friendly way.
[1] http://git.gnome.org/browse/gmime/commit/?id=ed985397843a9da3745a8b5de3d1d652acd24724
[2] https://bugzilla.gnome.org/show_bug.cgi?id=651826
This new structure, notmuch_crypto_t, keeps all relevant crypto
contexts and parameters together, and will make it easier to pass the
stuff around and clean it up. The name of the crypto context inside
this new struct will change, to reflect that it is actually a GPG
context, which is a sub type of Crypto context. There are other types
of Crypto contexts (Pkcs7 in particular, which we hope to support) so
we want to be clear.
The new crypto.c contains functions to return the proper context from
the struct for a given protocol (and initialize it if needed), and to
cleanup a struct by releasing the crypto contexts.
