debian/notmuch
1
0
Fork 0
mirror of https://git.notmuchmail.org/git/notmuch synced 2024-11-22 02:48:08 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
notmuch/lib/indexopts.c

82 lines
2.4 KiB
C
Raw Normal View History

reindex: drop notmuch_param_t, use notmuch_indexopts_t instead There are at least three places in notmuch that can trigger an indexing action: * notmuch new * notmuch insert * notmuch reindex I have plans to add some indexing options (e.g. indexing the cleartext of encrypted parts, external filters, automated property injection) that should properly be available in all places where indexing happens. I also want those indexing options to be exposed by (and constrained by) the libnotmuch C API. This isn't yet an API break because we've never made a release with notmuch_param_t. These indexing options are relevant in the listed places (and in the libnotmuch analogues), but they aren't relevant in the other kinds of functionality that notmuch offers (e.g. dump/restore, tagging, search, show, reply). So i think a generic "param" object isn't well-suited for this case. In particular: * a param object sounds like it could contain parameters for some other (non-indexing) operation. This sounds confusing -- why would i pass non-indexing parameters to a function that only does indexing? * bremner suggests online a generic param object would actually be passed as a list of param objects, argv-style. In this case (at least in the obvious argv implementation), the params might be some sort of generic string. This introduces a problem where the API of the library doesn't grow as new options are added, which means that when code outside the library tries to use a feature, it first has to test for it, and have code to handle it not being available. The indexopts approach proposed here instead makes it clear at compile time and at dynamic link time that there is an explicit dependency on that feature, which allows automated tools to keep track of what's needed and keeps the actual code simple. My proposal adds the notmuch_indexopts_t as an opaque struct, so that we can extend the list of options without causing ABI breakage. The cost of this proposal appears to be that the "boilerplate" API increases a little bit, with a generic constructor and destructor function for the indexopts struct. More patches will follow that make use of this indexopts approach.
2017-08-18 01:14:26 +02:00
/* indexopts.c - options for indexing messages (currently a stub)
*
* Copyright © 2017 Daniel Kahn Gillmor
*
* 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
* along with this program. If not, see https://www.gnu.org/licenses/ .
*
* Author: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
*/
#include "notmuch-private.h"
lib: make indexopts pointers opaque There is no reason for anything outside the indexopts.c compilation unit to have access to structure members.
2021-06-12 15:26:16 +02:00
struct _notmuch_indexopts {
_notmuch_crypto_t crypto;
};
reindex: drop notmuch_param_t, use notmuch_indexopts_t instead There are at least three places in notmuch that can trigger an indexing action: * notmuch new * notmuch insert * notmuch reindex I have plans to add some indexing options (e.g. indexing the cleartext of encrypted parts, external filters, automated property injection) that should properly be available in all places where indexing happens. I also want those indexing options to be exposed by (and constrained by) the libnotmuch C API. This isn't yet an API break because we've never made a release with notmuch_param_t. These indexing options are relevant in the listed places (and in the libnotmuch analogues), but they aren't relevant in the other kinds of functionality that notmuch offers (e.g. dump/restore, tagging, search, show, reply). So i think a generic "param" object isn't well-suited for this case. In particular: * a param object sounds like it could contain parameters for some other (non-indexing) operation. This sounds confusing -- why would i pass non-indexing parameters to a function that only does indexing? * bremner suggests online a generic param object would actually be passed as a list of param objects, argv-style. In this case (at least in the obvious argv implementation), the params might be some sort of generic string. This introduces a problem where the API of the library doesn't grow as new options are added, which means that when code outside the library tries to use a feature, it first has to test for it, and have code to handle it not being available. The indexopts approach proposed here instead makes it clear at compile time and at dynamic link time that there is an explicit dependency on that feature, which allows automated tools to keep track of what's needed and keeps the actual code simple. My proposal adds the notmuch_indexopts_t as an opaque struct, so that we can extend the list of options without causing ABI breakage. The cost of this proposal appears to be that the "boilerplate" API increases a little bit, with a generic constructor and destructor function for the indexopts struct. More patches will follow that make use of this indexopts approach.
2017-08-18 01:14:26 +02:00
notmuch_indexopts_t *
index: implement notmuch_indexopts_t with try_decrypt This is currently mostly a wrapper around _notmuch_crypto_t that keeps its internals private and doesn't expose any of the GMime API. However, non-crypto indexing options might also be added later (e.g. filters or other transformations).
2017-10-21 04:25:38 +02:00
notmuch_database_get_default_indexopts (notmuch_database_t *db)
reindex: drop notmuch_param_t, use notmuch_indexopts_t instead There are at least three places in notmuch that can trigger an indexing action: * notmuch new * notmuch insert * notmuch reindex I have plans to add some indexing options (e.g. indexing the cleartext of encrypted parts, external filters, automated property injection) that should properly be available in all places where indexing happens. I also want those indexing options to be exposed by (and constrained by) the libnotmuch C API. This isn't yet an API break because we've never made a release with notmuch_param_t. These indexing options are relevant in the listed places (and in the libnotmuch analogues), but they aren't relevant in the other kinds of functionality that notmuch offers (e.g. dump/restore, tagging, search, show, reply). So i think a generic "param" object isn't well-suited for this case. In particular: * a param object sounds like it could contain parameters for some other (non-indexing) operation. This sounds confusing -- why would i pass non-indexing parameters to a function that only does indexing? * bremner suggests online a generic param object would actually be passed as a list of param objects, argv-style. In this case (at least in the obvious argv implementation), the params might be some sort of generic string. This introduces a problem where the API of the library doesn't grow as new options are added, which means that when code outside the library tries to use a feature, it first has to test for it, and have code to handle it not being available. The indexopts approach proposed here instead makes it clear at compile time and at dynamic link time that there is an explicit dependency on that feature, which allows automated tools to keep track of what's needed and keeps the actual code simple. My proposal adds the notmuch_indexopts_t as an opaque struct, so that we can extend the list of options without causing ABI breakage. The cost of this proposal appears to be that the "boilerplate" API increases a little bit, with a generic constructor and destructor function for the indexopts struct. More patches will follow that make use of this indexopts approach.
2017-08-18 01:14:26 +02:00
{
config: define new option index.try_decrypt By default, notmuch won't try to decrypt on indexing. With this patch, we make it possible to indicate a per-database preference using the config variable "index.try_decrypt", which by default will be false. At indexing time, the database needs some way to know its internal defaults for how to index encrypted parts. It shouldn't be contingent on an external config file (since that can't be retrieved from the database object itself), so we store it in the database. This behaves similarly to the query.* configurations, which are also stored in the database itself, so we're not introducing any new dependencies by requiring that it be stored in the database.
2017-10-21 04:25:43 +02:00
notmuch_indexopts_t *ret = talloc_zero (db, notmuch_indexopts_t);
lib: run uncrustify This is the result of running $ uncrustify --replace --config ../devel/uncrustify.cfg *.c *.h *.cc in the lib directory
2019-06-13 12:55:35 +02:00
if (! ret)
config: define new option index.try_decrypt By default, notmuch won't try to decrypt on indexing. With this patch, we make it possible to indicate a per-database preference using the config variable "index.try_decrypt", which by default will be false. At indexing time, the database needs some way to know its internal defaults for how to index encrypted parts. It shouldn't be contingent on an external config file (since that can't be retrieved from the database object itself), so we store it in the database. This behaves similarly to the query.* configurations, which are also stored in the database itself, so we're not introducing any new dependencies by requiring that it be stored in the database.
2017-10-21 04:25:43 +02:00
return ret;
cli/new, insert, reindex: change index.decrypt to "auto" by default The new "auto" decryption policy is not only good for "notmuch show" and "notmuch reindex". It's also useful for indexing messages -- there's no good reason to not try to go ahead and index the cleartext of a message that we have a stashed session key for. This change updates the defaults and tunes the test suite to make sure that they have taken effect.
2017-12-08 07:23:59 +01:00
ret->crypto.decrypt = NOTMUCH_DECRYPT_AUTO;
config: define new option index.try_decrypt By default, notmuch won't try to decrypt on indexing. With this patch, we make it possible to indicate a per-database preference using the config variable "index.try_decrypt", which by default will be false. At indexing time, the database needs some way to know its internal defaults for how to index encrypted parts. It shouldn't be contingent on an external config file (since that can't be retrieved from the database object itself), so we store it in the database. This behaves similarly to the query.* configurations, which are also stored in the database itself, so we're not introducing any new dependencies by requiring that it be stored in the database.
2017-10-21 04:25:43 +02:00
lib: run uncrustify This is the result of running $ uncrustify --replace --config ../devel/uncrustify.cfg *.c *.h *.cc in the lib directory
2019-06-13 12:55:35 +02:00
char *decrypt_policy;
lib: convert notmuch decryption policy to an enum Future patches in this series will introduce new policies; this merely readies the way for them. We also convert --try-decrypt to a keyword argument instead of a boolean.
2017-12-08 07:23:52 +01:00
notmuch_status_t err = notmuch_database_get_config (db, "index.decrypt", &decrypt_policy);
lib: run uncrustify This is the result of running $ uncrustify --replace --config ../devel/uncrustify.cfg *.c *.h *.cc in the lib directory
2021-03-13 13:45:34 +01:00
config: define new option index.try_decrypt By default, notmuch won't try to decrypt on indexing. With this patch, we make it possible to indicate a per-database preference using the config variable "index.try_decrypt", which by default will be false. At indexing time, the database needs some way to know its internal defaults for how to index encrypted parts. It shouldn't be contingent on an external config file (since that can't be retrieved from the database object itself), so we store it in the database. This behaves similarly to the query.* configurations, which are also stored in the database itself, so we're not introducing any new dependencies by requiring that it be stored in the database.
2017-10-21 04:25:43 +02:00
if (err)
lib: return NULL from n_d_get_default_indexopts on error This is a rare and probably serious programming error, so better not to silently return a default value.
2020-08-01 14:25:50 +02:00
return NULL;
config: define new option index.try_decrypt By default, notmuch won't try to decrypt on indexing. With this patch, we make it possible to indicate a per-database preference using the config variable "index.try_decrypt", which by default will be false. At indexing time, the database needs some way to know its internal defaults for how to index encrypted parts. It shouldn't be contingent on an external config file (since that can't be retrieved from the database object itself), so we store it in the database. This behaves similarly to the query.* configurations, which are also stored in the database itself, so we're not introducing any new dependencies by requiring that it be stored in the database.
2017-10-21 04:25:43 +02:00
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_policy) {
lib: run uncrustify This is the result of running $ uncrustify --replace --config ../devel/uncrustify.cfg *.c *.h *.cc in the lib directory
2019-06-13 12:55:35 +02:00
if ((! (strcasecmp (decrypt_policy, "true"))) ||
(! (strcasecmp (decrypt_policy, "yes"))) ||
(! (strcasecmp (decrypt_policy, "1"))))
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_indexopts_set_decrypt_policy (ret, NOTMUCH_DECRYPT_TRUE);
lib: run uncrustify This is the result of running $ uncrustify --replace --config ../devel/uncrustify.cfg *.c *.h *.cc in the lib directory
2019-06-13 12:55:35 +02:00
else if ((! (strcasecmp (decrypt_policy, "false"))) ||
(! (strcasecmp (decrypt_policy, "no"))) ||
(! (strcasecmp (decrypt_policy, "0"))))
cli/new, insert, reindex: change index.decrypt to "auto" by default The new "auto" decryption policy is not only good for "notmuch show" and "notmuch reindex". It's also useful for indexing messages -- there's no good reason to not try to go ahead and index the cleartext of a message that we have a stashed session key for. This change updates the defaults and tunes the test suite to make sure that they have taken effect.
2017-12-08 07:23:59 +01:00
notmuch_indexopts_set_decrypt_policy (ret, NOTMUCH_DECRYPT_FALSE);
lib: run uncrustify This is the result of running $ uncrustify --replace --config ../devel/uncrustify.cfg *.c *.h *.cc in the lib directory
2019-06-13 12:55:35 +02:00
else if (! strcasecmp (decrypt_policy, "nostash"))
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
notmuch_indexopts_set_decrypt_policy (ret, NOTMUCH_DECRYPT_NOSTASH);
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
}
config: define new option index.try_decrypt By default, notmuch won't try to decrypt on indexing. With this patch, we make it possible to indicate a per-database preference using the config variable "index.try_decrypt", which by default will be false. At indexing time, the database needs some way to know its internal defaults for how to index encrypted parts. It shouldn't be contingent on an external config file (since that can't be retrieved from the database object itself), so we store it in the database. This behaves similarly to the query.* configurations, which are also stored in the database itself, so we're not introducing any new dependencies by requiring that it be stored in the database.
2017-10-21 04:25:43 +02:00
lib: convert notmuch decryption policy to an enum Future patches in this series will introduce new policies; this merely readies the way for them. We also convert --try-decrypt to a keyword argument instead of a boolean.
2017-12-08 07:23:52 +01:00
free (decrypt_policy);
config: define new option index.try_decrypt By default, notmuch won't try to decrypt on indexing. With this patch, we make it possible to indicate a per-database preference using the config variable "index.try_decrypt", which by default will be false. At indexing time, the database needs some way to know its internal defaults for how to index encrypted parts. It shouldn't be contingent on an external config file (since that can't be retrieved from the database object itself), so we store it in the database. This behaves similarly to the query.* configurations, which are also stored in the database itself, so we're not introducing any new dependencies by requiring that it be stored in the database.
2017-10-21 04:25:43 +02:00
return ret;
index: implement notmuch_indexopts_t with try_decrypt This is currently mostly a wrapper around _notmuch_crypto_t that keeps its internals private and doesn't expose any of the GMime API. However, non-crypto indexing options might also be added later (e.g. filters or other transformations).
2017-10-21 04:25:38 +02:00
}
notmuch_status_t
indexopts: change _try_decrypt to _decrypt_policy This terminology makes it clearer what's going on at the API layer, and paves the way for future changesets that offer more nuanced decryption policy.
2017-12-08 07:23:51 +01:00
notmuch_indexopts_set_decrypt_policy (notmuch_indexopts_t *indexopts,
lib: convert notmuch decryption policy to an enum Future patches in this series will introduce new policies; this merely readies the way for them. We also convert --try-decrypt to a keyword argument instead of a boolean.
2017-12-08 07:23:52 +01:00
notmuch_decryption_policy_t decrypt_policy)
index: implement notmuch_indexopts_t with try_decrypt This is currently mostly a wrapper around _notmuch_crypto_t that keeps its internals private and doesn't expose any of the GMime API. However, non-crypto indexing options might also be added later (e.g. filters or other transformations).
2017-10-21 04:25:38 +02:00
{
lib: run uncrustify This is the result of running $ uncrustify --replace --config ../devel/uncrustify.cfg *.c *.h *.cc in the lib directory
2019-06-13 12:55:35 +02:00
if (! indexopts)
index: implement notmuch_indexopts_t with try_decrypt This is currently mostly a wrapper around _notmuch_crypto_t that keeps its internals private and doesn't expose any of the GMime API. However, non-crypto indexing options might also be added later (e.g. filters or other transformations).
2017-10-21 04:25:38 +02:00
return NOTMUCH_STATUS_NULL_POINTER;
indexopts: change _try_decrypt to _decrypt_policy This terminology makes it clearer what's going on at the API layer, and paves the way for future changesets that offer more nuanced decryption policy.
2017-12-08 07:23:51 +01:00
indexopts->crypto.decrypt = decrypt_policy;
index: implement notmuch_indexopts_t with try_decrypt This is currently mostly a wrapper around _notmuch_crypto_t that keeps its internals private and doesn't expose any of the GMime API. However, non-crypto indexing options might also be added later (e.g. filters or other transformations).
2017-10-21 04:25:38 +02:00
return NOTMUCH_STATUS_SUCCESS;
}
lib: convert notmuch decryption policy to an enum Future patches in this series will introduce new policies; this merely readies the way for them. We also convert --try-decrypt to a keyword argument instead of a boolean.
2017-12-08 07:23:52 +01:00
notmuch_decryption_policy_t
indexopts: change _try_decrypt to _decrypt_policy This terminology makes it clearer what's going on at the API layer, and paves the way for future changesets that offer more nuanced decryption policy.
2017-12-08 07:23:51 +01:00
notmuch_indexopts_get_decrypt_policy (const notmuch_indexopts_t *indexopts)
index: implement notmuch_indexopts_t with try_decrypt This is currently mostly a wrapper around _notmuch_crypto_t that keeps its internals private and doesn't expose any of the GMime API. However, non-crypto indexing options might also be added later (e.g. filters or other transformations).
2017-10-21 04:25:38 +02:00
{
lib: run uncrustify This is the result of running $ uncrustify --replace --config ../devel/uncrustify.cfg *.c *.h *.cc in the lib directory
2019-06-13 12:55:35 +02:00
if (! indexopts)
index: implement notmuch_indexopts_t with try_decrypt This is currently mostly a wrapper around _notmuch_crypto_t that keeps its internals private and doesn't expose any of the GMime API. However, non-crypto indexing options might also be added later (e.g. filters or other transformations).
2017-10-21 04:25:38 +02:00
return false;
return indexopts->crypto.decrypt;
reindex: drop notmuch_param_t, use notmuch_indexopts_t instead There are at least three places in notmuch that can trigger an indexing action: * notmuch new * notmuch insert * notmuch reindex I have plans to add some indexing options (e.g. indexing the cleartext of encrypted parts, external filters, automated property injection) that should properly be available in all places where indexing happens. I also want those indexing options to be exposed by (and constrained by) the libnotmuch C API. This isn't yet an API break because we've never made a release with notmuch_param_t. These indexing options are relevant in the listed places (and in the libnotmuch analogues), but they aren't relevant in the other kinds of functionality that notmuch offers (e.g. dump/restore, tagging, search, show, reply). So i think a generic "param" object isn't well-suited for this case. In particular: * a param object sounds like it could contain parameters for some other (non-indexing) operation. This sounds confusing -- why would i pass non-indexing parameters to a function that only does indexing? * bremner suggests online a generic param object would actually be passed as a list of param objects, argv-style. In this case (at least in the obvious argv implementation), the params might be some sort of generic string. This introduces a problem where the API of the library doesn't grow as new options are added, which means that when code outside the library tries to use a feature, it first has to test for it, and have code to handle it not being available. The indexopts approach proposed here instead makes it clear at compile time and at dynamic link time that there is an explicit dependency on that feature, which allows automated tools to keep track of what's needed and keeps the actual code simple. My proposal adds the notmuch_indexopts_t as an opaque struct, so that we can extend the list of options without causing ABI breakage. The cost of this proposal appears to be that the "boilerplate" API increases a little bit, with a generic constructor and destructor function for the indexopts struct. More patches will follow that make use of this indexopts approach.
2017-08-18 01:14:26 +02:00
}
void
notmuch_indexopts_destroy (notmuch_indexopts_t *indexopts)
{
talloc_free (indexopts);
}
Reference in a new issue Copy permalink