debian/notmuch
1
0
Fork 0
mirror of https://git.notmuchmail.org/git/notmuch synced 2024-11-21 18:38:08 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
notmuch/util/crypto.c

222 lines
6.4 KiB
C
Raw Normal View History

cli: new crypto structure to store crypto contexts and parameters, and functions to support it 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.
2012-05-26 20:45:41 +02:00
/* notmuch - Not much of an email program, (just index and search)
*
* Copyright © 2012 Jameson Rollins
*
* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, either version 3 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
Use https instead of http where possible 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.
2016-06-02 18:26:14 +02:00
* along with this program. If not, see https://www.gnu.org/licenses/ .
cli: new crypto structure to store crypto contexts and parameters, and functions to support it 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.
2012-05-26 20:45:41 +02:00
*
* Authors: Jameson Rollins <jrollins@finestructure.net>
*/
crypto: move into libnotmuch_util This prepares us for using the crypto object in both libnotmuch and the client.
2017-10-17 21:09:55 +02:00
#include "crypto.h"
#include <strings.h>
#define unused(x) x __attribute__ ((unused))
#define ARRAY_SIZE(arr) (sizeof (arr) / sizeof (arr[0]))
crypto: Avoid explicit handling of GMimeCryptoContext in gmime 3 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)
2017-07-16 01:01:45 +02:00
#if (GMIME_MAJOR_VERSION < 3)
crypto: make shared crypto code behave library-like If we're going to reuse the crypto code across both the library and the client, then it needs to report error states properly and not write to stderr.
2017-10-17 21:09:56 +02:00
/* Create or pass on a GPG context (GMime 2.6) */
static notmuch_status_t
get_gpg_context (_notmuch_crypto_t *crypto, GMimeCryptoContext **ctx)
cli: crypto: abstract gpg context creation for clarity 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.
2013-03-30 14:53:15 +01:00
{
crypto: make shared crypto code behave library-like If we're going to reuse the crypto code across both the library and the client, then it needs to report error states properly and not write to stderr.
2017-10-17 21:09:56 +02:00
if (ctx == NULL || crypto == NULL)
return NOTMUCH_STATUS_NULL_POINTER;
cli: crypto: abstract gpg context creation for clarity 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.
2013-03-30 14:53:15 +01:00
crypto: make shared crypto code behave library-like If we're going to reuse the crypto code across both the library and the client, then it needs to report error states properly and not write to stderr.
2017-10-17 21:09:56 +02:00
if (crypto->gpgctx) {
*ctx = crypto->gpgctx;
return NOTMUCH_STATUS_SUCCESS;
}
crypto: refactor context creation to facilitate further work Let the context creation functions decide how to handle multiple calls and cache the crypto context. No functional changes.
2015-12-14 14:38:50 +01:00
cli: crypto: abstract gpg context creation for clarity 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.
2013-03-30 14:53:15 +01:00
/* TODO: GMimePasswordRequestFunc */
crypto: make shared crypto code behave library-like If we're going to reuse the crypto code across both the library and the client, then it needs to report error states properly and not write to stderr.
2017-10-17 21:09:56 +02:00
crypto->gpgctx = g_mime_gpg_context_new (NULL, crypto->gpgpath ? crypto->gpgpath : "gpg");
if (! crypto->gpgctx) {
return NOTMUCH_STATUS_FAILED_CRYPTO_CONTEXT_CREATION;
crypto: refactor context creation to facilitate further work Let the context creation functions decide how to handle multiple calls and cache the crypto context. No functional changes.
2015-12-14 14:38:50 +01:00
}
cli: crypto: abstract gpg context creation for clarity 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.
2013-03-30 14:53:15 +01:00
crypto: make shared crypto code behave library-like If we're going to reuse the crypto code across both the library and the client, then it needs to report error states properly and not write to stderr.
2017-10-17 21:09:56 +02:00
g_mime_gpg_context_set_use_agent ((GMimeGpgContext *) crypto->gpgctx, true);
g_mime_gpg_context_set_always_trust ((GMimeGpgContext *) crypto->gpgctx, false);
cli: crypto: abstract gpg context creation for clarity 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.
2013-03-30 14:53:15 +01:00
crypto: make shared crypto code behave library-like If we're going to reuse the crypto code across both the library and the client, then it needs to report error states properly and not write to stderr.
2017-10-17 21:09:56 +02:00
*ctx = crypto->gpgctx;
return NOTMUCH_STATUS_SUCCESS;
cli: crypto: abstract gpg context creation for clarity 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.
2013-03-30 14:53:15 +01:00
}
crypto: make shared crypto code behave library-like If we're going to reuse the crypto code across both the library and the client, then it needs to report error states properly and not write to stderr.
2017-10-17 21:09:56 +02:00
/* Create or pass on a PKCS7 context (GMime 2.6) */
static notmuch_status_t
get_pkcs7_context (_notmuch_crypto_t *crypto, GMimeCryptoContext **ctx)
cli: crypto: S/MIME verification support 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>.
2015-08-16 19:41:14 +02:00
{
crypto: make shared crypto code behave library-like If we're going to reuse the crypto code across both the library and the client, then it needs to report error states properly and not write to stderr.
2017-10-17 21:09:56 +02:00
if (ctx == NULL || crypto == NULL)
return NOTMUCH_STATUS_NULL_POINTER;
cli: crypto: S/MIME verification support 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>.
2015-08-16 19:41:14 +02:00
crypto: make shared crypto code behave library-like If we're going to reuse the crypto code across both the library and the client, then it needs to report error states properly and not write to stderr.
2017-10-17 21:09:56 +02:00
if (crypto->pkcs7ctx) {
*ctx = crypto->pkcs7ctx;
return NOTMUCH_STATUS_SUCCESS;
}
cli: crypto: S/MIME verification support 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>.
2015-08-16 19:41:14 +02:00
/* TODO: GMimePasswordRequestFunc */
crypto: make shared crypto code behave library-like If we're going to reuse the crypto code across both the library and the client, then it needs to report error states properly and not write to stderr.
2017-10-17 21:09:56 +02:00
crypto->pkcs7ctx = g_mime_pkcs7_context_new (NULL);
if (! crypto->pkcs7ctx) {
return NOTMUCH_STATUS_FAILED_CRYPTO_CONTEXT_CREATION;
cli: crypto: S/MIME verification support 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>.
2015-08-16 19:41:14 +02:00
}
crypto: make shared crypto code behave library-like If we're going to reuse the crypto code across both the library and the client, then it needs to report error states properly and not write to stderr.
2017-10-17 21:09:56 +02:00
g_mime_pkcs7_context_set_always_trust ((GMimePkcs7Context *) crypto->pkcs7ctx,
cli: convert notmuch_bool_t to stdbool 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.
2017-10-07 10:44:04 +02:00
false);
cli: crypto: S/MIME verification support 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>.
2015-08-16 19:41:14 +02:00
crypto: make shared crypto code behave library-like If we're going to reuse the crypto code across both the library and the client, then it needs to report error states properly and not write to stderr.
2017-10-17 21:09:56 +02:00
*ctx = crypto->pkcs7ctx;
return NOTMUCH_STATUS_SUCCESS;
cli: crypto: S/MIME verification support 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>.
2015-08-16 19:41:14 +02:00
}
crypto: make crypto ctx initialization an array Make it trivial to add handlers for new protocols without duplicating code. No functional changes.
2015-12-14 14:38:51 +01:00
static const struct {
const char *protocol;
crypto: make shared crypto code behave library-like If we're going to reuse the crypto code across both the library and the client, then it needs to report error states properly and not write to stderr.
2017-10-17 21:09:56 +02:00
notmuch_status_t (*get_context) (_notmuch_crypto_t *crypto, GMimeCryptoContext **ctx);
crypto: make crypto ctx initialization an array Make it trivial to add handlers for new protocols without duplicating code. No functional changes.
2015-12-14 14:38:51 +01:00
} protocols[] = {
{
.protocol = "application/pgp-signature",
crypto: make shared crypto code behave library-like If we're going to reuse the crypto code across both the library and the client, then it needs to report error states properly and not write to stderr.
2017-10-17 21:09:56 +02:00
.get_context = get_gpg_context,
crypto: make crypto ctx initialization an array Make it trivial to add handlers for new protocols without duplicating code. No functional changes.
2015-12-14 14:38:51 +01:00
},
{
.protocol = "application/pgp-encrypted",
crypto: make shared crypto code behave library-like If we're going to reuse the crypto code across both the library and the client, then it needs to report error states properly and not write to stderr.
2017-10-17 21:09:56 +02:00
.get_context = get_gpg_context,
crypto: make crypto ctx initialization an array Make it trivial to add handlers for new protocols without duplicating code. No functional changes.
2015-12-14 14:38:51 +01:00
},
cli: crypto: S/MIME verification support 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>.
2015-08-16 19:41:14 +02:00
{
.protocol = "application/pkcs7-signature",
crypto: make shared crypto code behave library-like If we're going to reuse the crypto code across both the library and the client, then it needs to report error states properly and not write to stderr.
2017-10-17 21:09:56 +02:00
.get_context = get_pkcs7_context,
cli: crypto: S/MIME verification support 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>.
2015-08-16 19:41:14 +02:00
},
{
.protocol = "application/x-pkcs7-signature",
crypto: make shared crypto code behave library-like If we're going to reuse the crypto code across both the library and the client, then it needs to report error states properly and not write to stderr.
2017-10-17 21:09:56 +02:00
.get_context = get_pkcs7_context,
cli: crypto: S/MIME verification support 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>.
2015-08-16 19:41:14 +02:00
},
crypto: make crypto ctx initialization an array Make it trivial to add handlers for new protocols without duplicating code. No functional changes.
2015-12-14 14:38:51 +01:00
};
cli: new crypto structure to store crypto contexts and parameters, and functions to support it 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.
2012-05-26 20:45:41 +02:00
/* for the specified protocol return the context pointer (initializing
* if needed) */
crypto: make shared crypto code behave library-like If we're going to reuse the crypto code across both the library and the client, then it needs to report error states properly and not write to stderr.
2017-10-17 21:09:56 +02:00
notmuch_status_t
_notmuch_crypto_get_gmime_ctx_for_protocol (_notmuch_crypto_t *crypto,
const char *protocol,
GMimeCryptoContext **ctx)
cli: new crypto structure to store crypto contexts and parameters, and functions to support it 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.
2012-05-26 20:45:41 +02:00
{
crypto: make shared crypto code behave library-like If we're going to reuse the crypto code across both the library and the client, then it needs to report error states properly and not write to stderr.
2017-10-17 21:09:56 +02:00
if (! protocol)
return NOTMUCH_STATUS_MALFORMED_CRYPTO_PROTOCOL;
crypto: return NULL cryptoctx if protocol string is empty. 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.)
2013-07-19 17:36:12 +02:00
cli: new crypto structure to store crypto contexts and parameters, and functions to support it 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.
2012-05-26 20:45:41 +02:00
/* As per RFC 1847 section 2.1: "the [protocol] value token is
* comprised of the type and sub-type tokens of the Content-Type".
* As per RFC 1521 section 2: "Content-Type values, subtypes, and
* parameter names as defined in this document are
* case-insensitive." Thus, we use strcasecmp for the protocol.
*/
crypto: make shared crypto code behave library-like If we're going to reuse the crypto code across both the library and the client, then it needs to report error states properly and not write to stderr.
2017-10-17 21:09:56 +02:00
for (size_t i = 0; i < ARRAY_SIZE (protocols); i++) {
crypto: make crypto ctx initialization an array Make it trivial to add handlers for new protocols without duplicating code. No functional changes.
2015-12-14 14:38:51 +01:00
if (strcasecmp (protocol, protocols[i].protocol) == 0)
crypto: make shared crypto code behave library-like If we're going to reuse the crypto code across both the library and the client, then it needs to report error states properly and not write to stderr.
2017-10-17 21:09:56 +02:00
return protocols[i].get_context (crypto, ctx);
cli: new crypto structure to store crypto contexts and parameters, and functions to support it 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.
2012-05-26 20:45:41 +02:00
}
crypto: make shared crypto code behave library-like If we're going to reuse the crypto code across both the library and the client, then it needs to report error states properly and not write to stderr.
2017-10-17 21:09:56 +02:00
return NOTMUCH_STATUS_UNKNOWN_CRYPTO_PROTOCOL;
cli: new crypto structure to store crypto contexts and parameters, and functions to support it 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.
2012-05-26 20:45:41 +02:00
}
crypto: _notmuch_crypto_cleanup should return void There's no chance that _notmuch_crypto_cleanup() will ever return anything other than 0, and no one ever checks its return value anyway. So make it return void instead of int.
2017-10-10 07:49:04 +02:00
void
crypto: rename notmuch_crypto_t to _notmuch_crypto_t 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.
2017-10-10 07:49:02 +02:00
_notmuch_crypto_cleanup (_notmuch_crypto_t *crypto)
cli: new crypto structure to store crypto contexts and parameters, and functions to support it 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.
2012-05-26 20:45:41 +02:00
{
if (crypto->gpgctx) {
g_object_unref (crypto->gpgctx);
crypto->gpgctx = NULL;
}
cli: crypto: S/MIME verification support 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>.
2015-08-16 19:41:14 +02:00
if (crypto->pkcs7ctx) {
g_object_unref (crypto->pkcs7ctx);
crypto->pkcs7ctx = NULL;
}
cli: new crypto structure to store crypto contexts and parameters, and functions to support it 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.
2012-05-26 20:45:41 +02:00
}
crypto: Avoid explicit handling of GMimeCryptoContext in gmime 3 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)
2017-07-16 01:01:45 +02:00
#else
crypto: _notmuch_crypto_cleanup should return void There's no chance that _notmuch_crypto_cleanup() will ever return anything other than 0, and no one ever checks its return value anyway. So make it return void instead of int.
2017-10-10 07:49:04 +02:00
void _notmuch_crypto_cleanup (unused(_notmuch_crypto_t *crypto))
crypto: Avoid explicit handling of GMimeCryptoContext in gmime 3 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)
2017-07-16 01:01:45 +02:00
{
}
#endif
crypto: add _notmuch_crypto_decrypt wrapper function We will use this centralized function to consolidate the awkward behavior around different gmime versions. It's only invoked from two places: mime-node.c's node_decrypt_and_verify() and lib/index.cc's _index_encrypted_mime_part(). However, those two places have some markedly distinct logic, so the interface for this _notmuch_crypto_decrypt function is going to get a little bit clunky. It's worthwhile, though, for the sake of keeping these #if directives reasonably well-contained.
2017-11-30 09:59:27 +01:00
GMimeObject *
crypto: record whether an actual decryption attempt happened In our consolidation of _notmuch_crypto_decrypt, the callers lost track a little bit of whether any actual decryption was attempted. Now that we have the more-subtle "auto" policy, it's possible that _notmuch_crypto_decrypt could be called without having any actual decryption take place. This change lets the callers be a little bit smarter about whether or not any decryption was actually attempted.
2017-12-08 07:23:58 +01:00
_notmuch_crypto_decrypt (bool *attempted,
notmuch_decryption_policy_t decrypt,
crypto: new decryption policy "auto" This new automatic decryption policy should make it possible to decrypt messages that we have stashed session keys for, without incurring a call to the user's asymmetric keys.
2017-12-08 07:23:53 +01:00
notmuch_message_t *message,
crypto: use stashed session-key properties for decryption, if available When doing any decryption, if the notmuch database knows of any session keys associated with the message in question, try them before defaulting to using default symmetric crypto. This changeset does the primary work in _notmuch_crypto_decrypt, which grows some new parameters to handle it. The primary advantage this patch offers is a significant speedup when rendering large encrypted threads ("notmuch show") if session keys happen to be cached. Additionally, it permits message composition without access to asymmetric secret keys ("notmuch reply"); and it permits recovering a cleartext index when reindexing after a "notmuch restore" for those messages that already have a session key stored. Note that we may try multiple decryptions here (e.g. if there are multiple session keys in the database), but we will ignore and throw away all the GMime errors except for those that come from last decryption attempt. Since we don't necessarily know at the time of the decryption that this *is* the last decryption attempt, we'll ask for the errors each time anyway. This does nothing if no session keys are stashed in the database, which is fine. Actually stashing session keys in the database will come as a subsequent patch.
2017-11-30 09:59:29 +01:00
g_mime_3_unused(GMimeCryptoContext* crypto_ctx),
crypto: add _notmuch_crypto_decrypt wrapper function We will use this centralized function to consolidate the awkward behavior around different gmime versions. It's only invoked from two places: mime-node.c's node_decrypt_and_verify() and lib/index.cc's _index_encrypted_mime_part(). However, those two places have some markedly distinct logic, so the interface for this _notmuch_crypto_decrypt function is going to get a little bit clunky. It's worthwhile, though, for the sake of keeping these #if directives reasonably well-contained.
2017-11-30 09:59:27 +01:00
GMimeMultipartEncrypted *part,
GMimeDecryptResult **decrypt_result,
GError **err)
{
GMimeObject *ret = NULL;
crypto: new decryption policy "auto" This new automatic decryption policy should make it possible to decrypt messages that we have stashed session keys for, without incurring a call to the user's asymmetric keys.
2017-12-08 07:23:53 +01:00
if (decrypt == NOTMUCH_DECRYPT_FALSE)
return NULL;
crypto: add _notmuch_crypto_decrypt wrapper function We will use this centralized function to consolidate the awkward behavior around different gmime versions. It's only invoked from two places: mime-node.c's node_decrypt_and_verify() and lib/index.cc's _index_encrypted_mime_part(). However, those two places have some markedly distinct logic, so the interface for this _notmuch_crypto_decrypt function is going to get a little bit clunky. It's worthwhile, though, for the sake of keeping these #if directives reasonably well-contained.
2017-11-30 09:59:27 +01:00
crypto: use stashed session-key properties for decryption, if available When doing any decryption, if the notmuch database knows of any session keys associated with the message in question, try them before defaulting to using default symmetric crypto. This changeset does the primary work in _notmuch_crypto_decrypt, which grows some new parameters to handle it. The primary advantage this patch offers is a significant speedup when rendering large encrypted threads ("notmuch show") if session keys happen to be cached. Additionally, it permits message composition without access to asymmetric secret keys ("notmuch reply"); and it permits recovering a cleartext index when reindexing after a "notmuch restore" for those messages that already have a session key stored. Note that we may try multiple decryptions here (e.g. if there are multiple session keys in the database), but we will ignore and throw away all the GMime errors except for those that come from last decryption attempt. Since we don't necessarily know at the time of the decryption that this *is* the last decryption attempt, we'll ask for the errors each time anyway. This does nothing if no session keys are stashed in the database, which is fine. Actually stashing session keys in the database will come as a subsequent patch.
2017-11-30 09:59:29 +01:00
/* the versions of notmuch that can support session key decryption */
#if HAVE_GMIME_SESSION_KEYS
if (message) {
notmuch_message_properties_t *list = NULL;
for (list = notmuch_message_get_properties (message, "session-key", TRUE);
notmuch_message_properties_valid (list); notmuch_message_properties_move_to_next (list)) {
if (err && *err) {
g_error_free (*err);
*err = NULL;
}
crypto: record whether an actual decryption attempt happened In our consolidation of _notmuch_crypto_decrypt, the callers lost track a little bit of whether any actual decryption was attempted. Now that we have the more-subtle "auto" policy, it's possible that _notmuch_crypto_decrypt could be called without having any actual decryption take place. This change lets the callers be a little bit smarter about whether or not any decryption was actually attempted.
2017-12-08 07:23:58 +01:00
if (attempted)
*attempted = true;
crypto: use stashed session-key properties for decryption, if available When doing any decryption, if the notmuch database knows of any session keys associated with the message in question, try them before defaulting to using default symmetric crypto. This changeset does the primary work in _notmuch_crypto_decrypt, which grows some new parameters to handle it. The primary advantage this patch offers is a significant speedup when rendering large encrypted threads ("notmuch show") if session keys happen to be cached. Additionally, it permits message composition without access to asymmetric secret keys ("notmuch reply"); and it permits recovering a cleartext index when reindexing after a "notmuch restore" for those messages that already have a session key stored. Note that we may try multiple decryptions here (e.g. if there are multiple session keys in the database), but we will ignore and throw away all the GMime errors except for those that come from last decryption attempt. Since we don't necessarily know at the time of the decryption that this *is* the last decryption attempt, we'll ask for the errors each time anyway. This does nothing if no session keys are stashed in the database, which is fine. Actually stashing session keys in the database will come as a subsequent patch.
2017-11-30 09:59:29 +01:00
#if (GMIME_MAJOR_VERSION < 3)
ret = g_mime_multipart_encrypted_decrypt_session (part,
crypto_ctx,
notmuch_message_properties_value (list),
decrypt_result, err);
#else
ret = g_mime_multipart_encrypted_decrypt (part,
GMIME_DECRYPT_NONE,
notmuch_message_properties_value (list),
decrypt_result, err);
#endif
if (ret)
break;
}
if (list)
notmuch_message_properties_destroy (list);
if (ret)
return ret;
}
#endif
if (err && *err) {
g_error_free (*err);
*err = NULL;
}
crypto: new decryption policy "auto" This new automatic decryption policy should make it possible to decrypt messages that we have stashed session keys for, without incurring a call to the user's asymmetric keys.
2017-12-08 07:23:53 +01:00
if (decrypt == NOTMUCH_DECRYPT_AUTO)
return ret;
crypto: record whether an actual decryption attempt happened In our consolidation of _notmuch_crypto_decrypt, the callers lost track a little bit of whether any actual decryption was attempted. Now that we have the more-subtle "auto" policy, it's possible that _notmuch_crypto_decrypt could be called without having any actual decryption take place. This change lets the callers be a little bit smarter about whether or not any decryption was actually attempted.
2017-12-08 07:23:58 +01:00
if (attempted)
*attempted = true;
crypto: add _notmuch_crypto_decrypt wrapper function We will use this centralized function to consolidate the awkward behavior around different gmime versions. It's only invoked from two places: mime-node.c's node_decrypt_and_verify() and lib/index.cc's _index_encrypted_mime_part(). However, those two places have some markedly distinct logic, so the interface for this _notmuch_crypto_decrypt function is going to get a little bit clunky. It's worthwhile, though, for the sake of keeping these #if directives reasonably well-contained.
2017-11-30 09:59:27 +01:00
#if (GMIME_MAJOR_VERSION < 3)
crypto: actually stash session keys when decrypt=true If you're going to store the cleartext index of an encrypted message, in most situations you might just as well store the session key. Doing this storage has efficiency and recoverability advantages. Combined with a schedule of regular OpenPGP subkey rotation and destruction, this can also offer security benefits, like "deletable e-mail", which is the store-and-forward analog to "forward secrecy". But wait, i hear you saying, i have a special need to store cleartext indexes but it's really bad for me to store session keys! Maybe (let's imagine) i get lots of e-mails with incriminating photos attached, and i want to be able to search for them by the text in the e-mail, but i don't want someone with access to the index to be actually able to see the photos themselves. Fret not, the next patch in this series will support your wacky uncommon use case.
2017-12-08 07:24:01 +01:00
#if HAVE_GMIME_SESSION_KEYS
gboolean oldgetsk = g_mime_crypto_context_get_retrieve_session_key (crypto_ctx);
crypto: add --decrypt=nostash to avoid stashing session keys Here's the configuration choice for people who want a cleartext index, but don't want stashed session keys. Interestingly, this "nostash" decryption policy is actually the same policy that should be used by "notmuch show" and "notmuch reply", since they never modify the index or database when they are invoked with --decrypt. We take advantage of this parallel to tune the behavior of those programs so that we're not requesting session keys from GnuPG during "show" and "reply" that we would then otherwise just throw away.
2017-12-08 07:24:02 +01:00
gboolean newgetsk = (decrypt == NOTMUCH_DECRYPT_TRUE && decrypt_result);
crypto: actually stash session keys when decrypt=true If you're going to store the cleartext index of an encrypted message, in most situations you might just as well store the session key. Doing this storage has efficiency and recoverability advantages. Combined with a schedule of regular OpenPGP subkey rotation and destruction, this can also offer security benefits, like "deletable e-mail", which is the store-and-forward analog to "forward secrecy". But wait, i hear you saying, i have a special need to store cleartext indexes but it's really bad for me to store session keys! Maybe (let's imagine) i get lots of e-mails with incriminating photos attached, and i want to be able to search for them by the text in the e-mail, but i don't want someone with access to the index to be actually able to see the photos themselves. Fret not, the next patch in this series will support your wacky uncommon use case.
2017-12-08 07:24:01 +01:00
if (newgetsk != oldgetsk)
/* This could return an error, but we can't do anything about it, so ignore it */
g_mime_crypto_context_set_retrieve_session_key (crypto_ctx, newgetsk, NULL);
#endif
crypto: add _notmuch_crypto_decrypt wrapper function We will use this centralized function to consolidate the awkward behavior around different gmime versions. It's only invoked from two places: mime-node.c's node_decrypt_and_verify() and lib/index.cc's _index_encrypted_mime_part(). However, those two places have some markedly distinct logic, so the interface for this _notmuch_crypto_decrypt function is going to get a little bit clunky. It's worthwhile, though, for the sake of keeping these #if directives reasonably well-contained.
2017-11-30 09:59:27 +01:00
ret = g_mime_multipart_encrypted_decrypt(part, crypto_ctx,
decrypt_result, err);
crypto: actually stash session keys when decrypt=true If you're going to store the cleartext index of an encrypted message, in most situations you might just as well store the session key. Doing this storage has efficiency and recoverability advantages. Combined with a schedule of regular OpenPGP subkey rotation and destruction, this can also offer security benefits, like "deletable e-mail", which is the store-and-forward analog to "forward secrecy". But wait, i hear you saying, i have a special need to store cleartext indexes but it's really bad for me to store session keys! Maybe (let's imagine) i get lots of e-mails with incriminating photos attached, and i want to be able to search for them by the text in the e-mail, but i don't want someone with access to the index to be actually able to see the photos themselves. Fret not, the next patch in this series will support your wacky uncommon use case.
2017-12-08 07:24:01 +01:00
#if HAVE_GMIME_SESSION_KEYS
if (newgetsk != oldgetsk)
g_mime_crypto_context_set_retrieve_session_key (crypto_ctx, oldgetsk, NULL);
#endif
crypto: add _notmuch_crypto_decrypt wrapper function We will use this centralized function to consolidate the awkward behavior around different gmime versions. It's only invoked from two places: mime-node.c's node_decrypt_and_verify() and lib/index.cc's _index_encrypted_mime_part(). However, those two places have some markedly distinct logic, so the interface for this _notmuch_crypto_decrypt function is going to get a little bit clunky. It's worthwhile, though, for the sake of keeping these #if directives reasonably well-contained.
2017-11-30 09:59:27 +01:00
#else
crypto: actually stash session keys when decrypt=true If you're going to store the cleartext index of an encrypted message, in most situations you might just as well store the session key. Doing this storage has efficiency and recoverability advantages. Combined with a schedule of regular OpenPGP subkey rotation and destruction, this can also offer security benefits, like "deletable e-mail", which is the store-and-forward analog to "forward secrecy". But wait, i hear you saying, i have a special need to store cleartext indexes but it's really bad for me to store session keys! Maybe (let's imagine) i get lots of e-mails with incriminating photos attached, and i want to be able to search for them by the text in the e-mail, but i don't want someone with access to the index to be actually able to see the photos themselves. Fret not, the next patch in this series will support your wacky uncommon use case.
2017-12-08 07:24:01 +01:00
GMimeDecryptFlags flags = GMIME_DECRYPT_NONE;
crypto: add --decrypt=nostash to avoid stashing session keys Here's the configuration choice for people who want a cleartext index, but don't want stashed session keys. Interestingly, this "nostash" decryption policy is actually the same policy that should be used by "notmuch show" and "notmuch reply", since they never modify the index or database when they are invoked with --decrypt. We take advantage of this parallel to tune the behavior of those programs so that we're not requesting session keys from GnuPG during "show" and "reply" that we would then otherwise just throw away.
2017-12-08 07:24:02 +01:00
if (decrypt == NOTMUCH_DECRYPT_TRUE && decrypt_result)
crypto: actually stash session keys when decrypt=true If you're going to store the cleartext index of an encrypted message, in most situations you might just as well store the session key. Doing this storage has efficiency and recoverability advantages. Combined with a schedule of regular OpenPGP subkey rotation and destruction, this can also offer security benefits, like "deletable e-mail", which is the store-and-forward analog to "forward secrecy". But wait, i hear you saying, i have a special need to store cleartext indexes but it's really bad for me to store session keys! Maybe (let's imagine) i get lots of e-mails with incriminating photos attached, and i want to be able to search for them by the text in the e-mail, but i don't want someone with access to the index to be actually able to see the photos themselves. Fret not, the next patch in this series will support your wacky uncommon use case.
2017-12-08 07:24:01 +01:00
flags |= GMIME_DECRYPT_EXPORT_SESSION_KEY;
ret = g_mime_multipart_encrypted_decrypt(part, flags, NULL,
crypto: add _notmuch_crypto_decrypt wrapper function We will use this centralized function to consolidate the awkward behavior around different gmime versions. It's only invoked from two places: mime-node.c's node_decrypt_and_verify() and lib/index.cc's _index_encrypted_mime_part(). However, those two places have some markedly distinct logic, so the interface for this _notmuch_crypto_decrypt function is going to get a little bit clunky. It's worthwhile, though, for the sake of keeping these #if directives reasonably well-contained.
2017-11-30 09:59:27 +01:00
decrypt_result, err);
#endif
return ret;
}
Reference in a new issue Copy permalink