crypto.gpg_path was only used when we built against gmime versions
before 3.0. Since we now depend on gmime 3.0.3 or later, it is
meaningless.
The removal of the field from the _notmuch_config struct would be an
ABI change if that struct were externally exposed, but it is not, so
it's safe to unilaterally remove it.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
These restrictions are meant to prevent incompatibilities with the
Xapian query parser (which will split at non-word characters) and
clashes with future notmuch builtin fields.
We don't do anything with this configuration information information
yet, but nonetheless add a couple of regression tests to make sure we
don't break standard functionality when we do use the configuration
information.
This will make it easier to add other prefixes that are stored in the
database, compared to special casing each one as "query." was. This
commit also adds the ability to validate keys with a given
prefix. This ability will be used in a future commit.
Note that we do keep ignoring the gpg_path configuration option,
though, to avoid breakage of existing installations. It is ignored
like any other unknown configuration option, but we at least document
that it is ignored so that people who find it in their legacy configs
can know that it's safe to drop.
signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
If the database path specified in the configuration file does *not*
start with a /, presume that it is relative to $HOME and modify the
path used to open the database accordingly.
the command-line interface for indexing (reindex, new, insert) used
--try-decrypt; and the configuration records used index.try_decrypt.
But by comparison with "show" and "reply", there doesn't seem to be
any reason for the "try" prefix.
This changeset adjusts the command-line interface and the
configuration interface.
For the moment, i've left indexopts_{set,get}_try_decrypt alone. The
subsequent changeset will address those.
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.
QUERY_STRING was only used in two places, both to test whether a
variable should be stored in (or retrieved from) the database.
Since other configuration variables might be stored in the database in
the future, consolidate that test into a single function.
We also document that these configuration options should not be placed
in the config file.
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 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.
When opening configuration file fails, ENOENT (file not found) is
handled specially -- in setup missing file is ok (often expected),
and otherwise user can be informed to run notmuch setup.
In any other case the the reason is unknown, so there is no other
option but to print generic error message to stderr.
Do not initialize each field separately. It's more robust to allocate
the config with zero initialization, and only set the non-zero
defaults individually.
Config files are currently read using glib's g_key_file_load_from_file
function which is very inconvenient because it's limited by design to read
only from "regular data files" in a filesystem. Because of this limitation
notmuch can't read configs from pipes, fifos, sockets, stdin, etc. Not even
"notmuch --config=/dev/stdin" works:
Error reading configuration file /dev/stdin: Not a regular file
So replace g_key_file_load_from_file with g_key_file_load_from_data which
gives us much more freedom to read configs from multiple sources.
This also helps the more security sensitive users: If someone has private
information in the config file, it can be encrypted on disk, then decrypted
in RAM and passed through a pipe directly to notmuch without the use of
intermediate plain text files.
Signed-off-by: Ioan-Adrian Ratiu <adi@adirat.com>
This support will be present only if the appropriate version of xapian
is available _and_ the user did not disable the feature when
building. So there really needs to be some way for the user to check.
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.
Most of the infrastructure here is general, only the validation/dispatch
is hardcoded to a particular prefix.
A notable change in behaviour is that notmuch-config now opens the
database e.g. on every call to list, which fails with an error message
if the database doesn't exit yet.
The function notmuch_exit_if_unmatched_db_uuid is split from
notmuch_process_shared_options because it needs an open notmuch
database.
There are two exceptional cases in uuid handling.
1) notmuch config and notmuch setup don't currently open the database,
so it doesn't make sense to check the UUID.
2) notmuch compact opens the database inside the library, so we either
need to open the database just to check uuid, or change the API.
In particular this fixes a recently encountered bug where the
"--config" argument to "notmuch setup" is silently ignored, which the
unpleasant consequence of overwriting the users config file.
Previously we set up a way for the top level notmuch command to choose
which gpg binary was invoked by libgmime. In this commit we add the
(mostly boilerplate) code to allow the notmuch-config command to read
and write this path, and use it in the appropriate struct.
Update tests for new default variable
Previously, if the user ran any subcommand that required a
configuration (e.g., notmuch new) but didn't have a configuration,
notmuch would give the rather un-friendly and un-actionable message
Error reading configuration file .notmuch-config: No such file or directory
Since this condition is expected for new users, this patch adds
specific handling for the file-not-found case to give a message that
is friendly and actionable.
the POSIX 2008 behaviour of realpath is not available everywhere so we
provide a simple wrapper function. We use (and provide) the gnu
extension canonicalize_file_name to make it cleaner to test for the
feature we need; otherwise we have to rely on realpath segfaulting if
the second argument is null.
Apart from the status codes for format mismatches, the non-zero exit
status codes have been arbitrary. Make the cli consistently return
either EXIT_SUCCESS or EXIT_FAILURE.
notmuch-config.c has the only use of the function named "index()" in the
notmuch source. Several other places use the equivalent function
"strchr()"; this patch just fixes notmuch-config.c to use strchr()
instead. (Solaris needs to include <strings.h> to get the prototype for
index(), and notmuch-config.c was failing to include that header, so it
wasn't compiling as-is.)
The use of realpath(3) in
commit 58ed67992d
Author: Jani Nikula <jani@nikula.org>
Date: Sun Apr 7 20:15:03 2013 +0300
cli: config: do not overwrite symlinks when saving config file
broke config file save when the file does not exist, which results in
'notmuch setup' always failing to create a new config file.
Fix by checking ENOENT from realpath(3).
Use realpath to canonicalize the config path before writing.
Previously 'notmuch setup' and 'notmuch config set' overwrote the
config file even if it was a symbolic link.
This allows specifying config file as a top level argument to notmuch,
and generally makes it possible to override config file options in
main(), without having to touch the subcommands.
If the config file does not exist, one will be created for the notmuch
main command and setup and help subcommands. Help is special in this
regard; the config is created just to avoid errors about missing
config, but it will not be saved.
This also makes notmuch config the talloc context for subcommands.
We now have a notmuch_config_is_new() function to query whether a
config was created or not. Change the notmuch_config_open() is_new
parameter into boolean create_new to determine whether the function
should create a new config if one doesn't exist. This reduces the
complexity of the API.
Keep track of whether the config is newly created, and add
notmuch_config_is_new() accessor function to query this.
This is to support anyone with a config handle to check this, instead
of just whoever called notmuch_config_open().
While one comment in generated .notmuch-config file looked good in the
source file notmuch-config.c, the generated output was inconsistently
wide -- even breaking the 80-column boundary.
Add a command to list all configuration items with their associated
values.
One use is as follows: a MUA may prefer to store data in a central
notmuch configuration file so that the data is accessible across
different machines, e.g. an addressbook. The list command helps
to implement features such as tab completion on the keys.
Require that 'config get' is passed exactly one additional argument,
instead of silently ignoring extra arguments. As a side-effect, produce
more specific error messages for the 'config' command as a whole.
This reverts
dfee0f9 man: remove search.exclude_tags from notmuch-config.1 for 0.12
e83409d NEWS: revert NEWS item for exclude tags for 0.12
e77b031 config: disable addition of exclude tags for 0.12
A new configuration key 'new.ignore' is used to determine which
files and directories user wants not to be scanned as new mails.
Mark the corresponding test as no longer broken.
This work merges my previous attempts and Andreas Amann's work
in id:"ylp7hi23mw8.fsf@tyndall.ie"
Moved static functions _config_get_list () and _config_set_list ()
closer to the beginning of file so that their definition is known
(without adding forward declarations) in upcoming changes.
Currently, the 'search.exclude_tags' option is automatically
set to "deleted;spam;" if it's missing from the config file.
This violates the Principle of Least Surprise, so *only* set
'search.exclude_tags' to "deleted;spam;" if we didn't find a
configuration file at all.
This patch is actually Austin Clements' work:
id:"20120117203211.GQ16740@mit.edu"
