[PATCH v2 03/10] tests: prepare for more crypto tests (using add_gnupg_home)

Move add_gnupg_home to test-lib.sh to prepare it for reuse. --- test/T350-crypto.sh | 17 - test/test-lib.sh| 15 +++ 2 files changed, 15 insertions(+), 17 deletions(-) diff --git a/test/T350-crypto.sh b/test/T350-crypto.sh index 1d408af7..e1b8fd83 100755 ---

[PATCH v2 04/10] 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). --- lib/add-message.cc| 9 - lib/indexopts.c

[PATCH v2 06/10] config: indexing defaults will be stored in the database.

At indexing time, the database needs to know its internal defaults. It shouldn't be contingent on an external config file (since that can't be retrieved from the database object itself). This behaves the same as the query.* configurations, which are also stored in the database itself, so we're

[PATCH v2 07/10] 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. --- doc/man1/notmuch-config.rst | 12 lib/indexopts.c | 16

[PATCH v2 08/10] cli/new: add --try-decrypt=(true|false)

Try to decrypt any encrypted parts of newly-discovered messages while indexing them. The cleartext of any successfully-decrypted messages will be indexed, with tags applied in the same form as from notmuch insert --try-decrypt=true. Note: if the deprecated crypto.gpg_path configuration option is

[PATCH] lib: index the content-type of the parts of encrypted messages

This is a logical followup to "lib: index the content type of signature parts", which will make it easier to record the message structure of all messages. --- lib/index.cc | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/lib/index.cc b/lib/index.cc index

Re: [PATCH 2/2] lib: index the content type of signature parts

On Wed 2017-09-13 22:13:35 +0300, Jani Nikula wrote: > It's useful (*) to be able to easily find messages with certain types > of signatures. Having the mimetype: prefix searches fail for some > content types is also genuinely surprising (*). Index the content type > of signature parts. > > While

Re: [PATCH 07/10] Define new config option index.try_decrypt

On Tue 2017-09-12 19:01:50 -0400, Daniel Kahn Gillmor wrote: > 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

[PATCH 08/10] add --try-decrypt=(true|false) to notmuch new

Try to decrypt any encrypted parts of newly-discovered messages while indexing them. The cleartext of any successfully-decrypted messages will be indexed, with tags applied in the same form as from notmuch insert --try-decrypt=true. Note: if the deprecated crypto.gpg_path configuration option is

[PATCH 05/10] 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). --- lib/add-message.cc| 9 - lib/indexopts.c

[PATCH 06/10] crypto: index encrypted parts when indexopts try_decrypt is set.

If we see index options that ask us to decrypt when indexing a message, and we encounter an encrypted part, we'll try to descend into it. If we can decrypt, we add the property index-decryption=success. If we can't decrypt (or recognize the encrypted type of mail), we add the property

[PATCH 04/10] tests: prepare for more crypto tests (using add_gnupg_home)

Move add_gnupg_home to test-lib.sh to prepare it for reuse. --- test/T350-crypto.sh | 17 - test/test-lib.sh| 15 +++ 2 files changed, 15 insertions(+), 17 deletions(-) diff --git a/test/T350-crypto.sh b/test/T350-crypto.sh index 1d408af7..e1b8fd83 100755 ---

[PATCH 02/10] crypto: Move crypto.c into libutil

ypto.c b/util/crypto.c similarity index 79% rename from crypto.c rename to util/crypto.c index cc45b885..97e8c8f4 100644 --- a/crypto.c +++ b/util/crypto.c @@ -16,18 +16,26 @@ * along with this program. If not, see https://www.gnu.org/licenses/ . * * Authors: Jameson Rollins <jroll...@fines

[PATCH 01/10] reorganize indexing of multipart/signed and multipart/encrypted

This makes no functional changes, but prepares the codebase for a cleaner changeset for dealing with indexing some encrypted messages in the clear. --- lib/index.cc | 42 ++ 1 file changed, 22 insertions(+), 20 deletions(-) diff --git a/lib/index.cc

[PATCH 10/10] add --try-decrypt=(true|false) to notmuch reindex

Try to decrypt any encrypted parts of newly-discovered messages while re-indexing them. The cleartext of any successfully-decrypted messages will be indexed, with tags applied in the same form as from notmuch insert --try-decrypt=true. Note: if the deprecated crypto.gpg_path configuration option

[PATCH 09/10] add --try-decrypt=(true|false) to notmuch insert

Allow an incoming message to be delivered while indexing the cleartext, on a per-message basis. This requires the secret keys for the message to be available. For the moment, the most functional approach is to ensure that gpg-agent is running and knows about any secret keys that might be useful

[PATCH 07/10] Define new config 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. --- doc/man1/notmuch-config.rst | 12 lib/indexopts.c | 16

[PATCH 03/10] 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. --- lib/database.cc | 6 lib/notmuch.h | 17 +++ mime-node.c | 7 - util/crypto.c | 89

Re: [PATCH v2] python: deprecated add_message calls index_file correctly and returns result

On Wed 2017-08-30 10:16:33 +0200, Gaute Hope wrote: > The deprecated Database.add_message now calls the new index_file with > correct number of arguments (without an extra `self`), and returns the > tuple from index_file - as it used to do before. > > This change also adds a DeprecationWarning to

Re: [Łukasz Stelmach] Bug#864493: notmuch: bash completion eats typed option

On Thu 2017-08-31 10:50:57 -0300, David Bremner wrote: > This eventually turned out to be a bug in the "npm" debian package, > since fixed upstream there. only if you actually purge npm itself :( on a system where npm is in the "config-files" state, it's entirely possible that the old/bad npm

[PATCH] fix documentation bug (leading quotes break documentation)

--- lib/notmuch.h | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/lib/notmuch.h b/lib/notmuch.h index 66ecb5fc..f26565f3 100644 --- a/lib/notmuch.h +++ b/lib/notmuch.h @@ -562,9 +562,10 @@ notmuch_database_get_directory (notmuch_database_t *database, * terms from the

[PATCH v2 1/3] lib: clarify description of notmuch_database_add_message

Since we're accumulating the index when we add a new file to the message, the semantics have slightly changed. This tries to align the documentation with the actual functionality. --- lib/notmuch.h | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/lib/notmuch.h

[PATCH v2 2/3] database: add n_d_index_file (deprecates n_d_add_message)

We need a way to pass parameters to the indexing functionality on the first index, not just on reindexing. The obvious place is in notmuch_database_add_message. But since modifying the argument list would break both API and ABI, we needed a new name. I considered

[PATCH v2 3/3] reindex: drop notmuch_param_t, use notmuch_indexopts_t instead

/indexopts.c @@ -0,0 +1,33 @@ +/* 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 +

Re: rendering and generating text/markdown parts

On Fri 2017-08-11 15:02:44 -0700, Dylan Baker wrote: > Natively no. I have a fairly minor patch to alot that would make it work if > the > type was text/markdown instead of text/plain. huh, i tried to set Content-Type: text/markdown in emacs mml-mode by just fiddling with the header but mml

Re: associating a property with a subpart of a message

On Tue 2017-08-08 14:02:56 -0400, David Bremner wrote: > A hybrid option would be to use a hash of the file + 1.2.1.1. address > scheme. My thinking here is a bit vague, but I can imagine such has hash > being useful either for content addressible mailstore, or for > disambiguating message-id

rendering and generating text/markdown parts

Using `Content-Type: text/markdown` --- [Over on LWN, some discussion came up about rendering and generating text/markdown variants of e-mails](https://lwn.net/Articles/730277/) This is similar to (but maybe simpler than) [a proposal that was discussed on the alot

[PATCH] fix typo

--- bindings/python/README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bindings/python/README b/bindings/python/README index fe7a2181..5bf076d2 100644 --- a/bindings/python/README +++ b/bindings/python/README @@ -3,7 +3,7 @@ notmuch -- The python interface to notmuch

[PATCH] completion: add bash completion for "notmuch reindex"

The main thing that notmuch reindex does is to use search terms, so we can reuse a bunch of the existing completion framework. --- completion/notmuch-completion.bash | 20 +++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/completion/notmuch-completion.bash

[PATCH 1/3] lib: clarify description of notmuch_database_add_message

Since we're accumulating the index when we add a new file to the message, the semantics have slightly changed. This tries to align the documentation with the actual functionality. --- lib/notmuch.h | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/lib/notmuch.h

[PATCH 3/3] reindex: drop notmuch_param_t, use notmuch_indexopts_t instead

00644 index ..2f9b841b --- /dev/null +++ b/lib/indexopts.c @@ -0,0 +1,33 @@ +/* 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 th

[PATCH 2/3] database: add n_d_index_file (deprecates n_d_add_message)

We need a way to pass parameters to the indexing functionality on the first index, not just on reindexing. The obvious place is in notmuch_database_add_message. But since modifying the argument list would break both API and ABI, we needed a new name. I considered

Re: a DoS vulnerability associated with conflated Message-IDs?

On Fri 2017-08-04 16:42:54 -0400, David Bremner wrote: > Peter Wang <noval...@gmail.com> writes: > >> On Thu, 08 Mar 2012 11:37:09 -0500, Daniel Kahn Gillmor >> <d...@fifthhorseman.net> wrote: >>> notmuch currently treats all messages with the same Messa

associating a property with a subpart of a message

hey folks-- I have some message properties i'd like to cache in notmuch that strictly apply to specific subparts of the message. (e.g. session keys for an encrypted part, signature verification status of a signed part) let's assume that for any given copy of a message, we have a reliable

[PATCH] remove obsolete lintian-override (see https://bugs.debian.org/865055)

--- debian/notmuch.lintian-overrides | 2 -- 1 file changed, 2 deletions(-) delete mode 100644 debian/notmuch.lintian-overrides diff --git a/debian/notmuch.lintian-overrides b/debian/notmuch.lintian-overrides deleted file mode 100644 index fb5bc076.. ---

[PATCH] do not use bullets in debian/NEWS

see lintian's debian-news-entry-uses-asterisk for justification --- debian/NEWS | 56 1 file changed, 28 insertions(+), 28 deletions(-) diff --git a/debian/NEWS b/debian/NEWS index 174c1303..bf661fe4 100644 --- a/debian/NEWS +++

[PATCH 9/9] use modern debian/copyright

--- debian/copyright | 17 + 1 file changed, 5 insertions(+), 12 deletions(-) diff --git a/debian/copyright b/debian/copyright index 1cc7a155..0931d9b9 100644 --- a/debian/copyright +++ b/debian/copyright @@ -1,7 +1,7 @@ -Format-Specification:

[PATCH 8/9] fix the generated documentation output

--- lib/notmuch.h | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/lib/notmuch.h b/lib/notmuch.h index d813612b..17f0872e 100644 --- a/lib/notmuch.h +++ b/lib/notmuch.h @@ -1568,11 +1568,11 @@ notmuch_message_maildir_flags_to_tags (notmuch_message_t *message); *

[PATCH 3/9] explicitly mark notmuch-emacs as transitional

--- debian/control | 2 ++ 1 file changed, 2 insertions(+) diff --git a/debian/control b/debian/control index 3700c04d..a30f4fcc 100644 --- a/debian/control +++ b/debian/control @@ -111,6 +111,8 @@ Description: Ruby interface to the notmuch mail search and index library functionality,

[PATCH 2/9] Bump standards version to 4.0.0 (no changes needed)

Some things that might be interesting (and are acceptable and supported under 4.0.0, though not required) are: * supporting DEB_BUILD_OPTIONS tag nodoc wihle tagging build-deps (we could put python-sphinx into , for example) * splitting out Build-Depends-Arch from Build-Depends ---

[PATCH 4/9] fix Python capitalization

--- debian/control | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/control b/debian/control index a30f4fcc..8581b506 100644 --- a/debian/control +++ b/debian/control @@ -75,7 +75,7 @@ Package: python-notmuch Architecture: all Section: python Depends: ${misc:Depends},

[PATCH 6/9] resolve lintian tag debhelper-but-no-misc-depends notmuch-emacs

This is likely not strictly necessary given that notmuch-emacs is a transitional package. But having a simple consistency until we eventually remove the transitional notmuch-emacs package seems ok too, and fewer arbitrary lintian warnings will make real lintian warnings more visible. ---

[PATCH 7/9] avoid false lintian warning about "iff"

--- debian/notmuch.lintian-overrides | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 debian/notmuch.lintian-overrides diff --git a/debian/notmuch.lintian-overrides b/debian/notmuch.lintian-overrides new file mode 100644 index ..fb5bc076 --- /dev/null +++

[PATCH 5/9] Fix orthography

--- bindings/python/docs/source/query.rst | 2 +- bindings/python/notmuch/thread.py | 2 +- doc/man1/notmuch-address.rst | 2 +- doc/man1/notmuch-insert.rst | 2 +- doc/man1/notmuch-new.rst | 2 +- doc/man1/notmuch.rst | 2 +- lib/notmuch.h

[PATCH 1/9] Drop duplicate Section header for notmuch-vim

Resolves lintian binary-control-field-duplicates-source --- debian/control | 1 - 1 file changed, 1 deletion(-) diff --git a/debian/control b/debian/control index 4e1feba1..8e55d669 100644 --- a/debian/control +++ b/debian/control @@ -130,7 +130,6 @@ Description: thread-based email index, search

[PATCH v2 2/4] cli/crypto: eliminated compiler warnings about unused arguments

From: David Bremner These are due to (excessively?) fancy macro definitions in gmime-extra.h --- mime-node.c| 4 ++-- util/gmime-extra.h | 2 ++ 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/mime-node.c b/mime-node.c index 7363e222..bc41b752 100644

[PATCH v2 1/4] cli/crypto: treat failure to create a crypto context as fatal.

From: David Bremner Silently ignoring signed/encrypted parts seems like the wrong idea, and it also complicates future gmime-3.0 compatibility changes. --- mime-node.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/mime-node.c b/mime-node.c index

[PATCH v2 3/4] crypto: Avoid explicit handling of GMimeCryptoContext in gmime 3

From: David Bremner 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

[PATCH v2 4/4] crypto: clean up unused definitions in gmime 3.0

From: David Bremner based on the same patch from dkg as the previous commit. --- notmuch-client.h | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/notmuch-client.h b/notmuch-client.h index 11aefbb4..ae37360b 100644 --- a/notmuch-client.h +++

Re: [PATCH 3/4] crypto: Avoid explicit handling of GMimeCryptoContext in gmime 3

Thanks for trying to talk me down from my ifdefery, Bremner :) I think this subseries looks reasonable, though: On Sat 2017-07-15 15:57:43 -0300, David Bremner wrote: > diff --git a/notmuch-reply.c b/notmuch-reply.c > index 40201b80..4df29b82 100644 > --- a/notmuch-reply.c > +++

Re: [PATCH] Avoid crashes in "notmuch reply" with gmime 3.0 when reply-to == sender

On Sat 2017-07-15 00:13:39 +0200, Daniel Kahn Gillmor wrote: > I'm currently publishing it currently on the gmime 3.0 branch (commit id > aeeded4307162bdc1c745d15cd3ccf5a2140bdf9) at > https://gitlab.com/dkg/notmuch if anyone wants to consider it (i'm > likely to rebase all non-mas

Re: [PATCH] Avoid crashes in "notmuch reply" with gmime 3.0 when reply-to == sender

On Sat 2017-07-15 00:03:35 +0200, Daniel Kahn Gillmor wrote: > Bremner found this fix. I'm just documenting it for posterity :) With this patch, and the preceding two patches, and my additional comments in the other gmime 3.0 thread, i think notmuch is ready for being able to build against gm

[PATCH] Avoid crashes in "notmuch reply" with gmime 3.0 when reply-to == sender

Bremner found this fix. I'm just documenting it for posterity :) --- notmuch-reply.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/notmuch-reply.c b/notmuch-reply.c index bb6b99fa..4f3f3859 100644 --- a/notmuch-reply.c +++ b/notmuch-reply.c @@ -286,7 +286,7 @@ static

[PATCH v2 1/2] Ensure that "notmuch reply" succeeds during testing.

In some (bad!) cases, "notmuch reply" might fail, or might even segfault. If this happens, it indicates a bug, and the test suite should notice it. --- test/T220-reply.sh | 71 +- 1 file changed, 43 insertions(+), 28 deletions(-) diff --git

[PATCH v2 2/2] Add additional munged reply-to tests

The reply-to munging code might behave differently whether there's an exact match on the strings or not, or whether the string is a raw addr-spec instead of an name-addr. These tests cover those variations (i also had to tweak json output further below when this new test was added). ---

Re: [PATCH 1/2] Ensure that "notmuch reply" succeeds during testing.

On Fri 2017-07-14 11:42:43 -0300, David Bremner wrote: > Daniel Kahn Gillmor <d...@fifthhorseman.net> writes: >> -output=$(notmuch reply id:${gen_msg_id}) >> +output=$(notmuch reply id:${gen_msg_id} || echo failed) > > I wonder if we're going to touch this code if

Re: [PATCH 2/2] Add additional munged reply-to tests

On Fri 2017-07-14 15:09:12 +0200, Daniel Kahn Gillmor wrote: > The reply-to munging code might behave differently whether there's an > exact match on the strings or not, or whether the string is a raw > addr-spec instead of an name-addr. These tests cover those > variations. This pai

Re: [PATCH 1/3] config: deprecate/drop crypto.gpg_path under gmime 2.6/3.0

On Fri 2017-07-14 15:12:00 +0200, Daniel Kahn Gillmor wrote: > 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 functiona

[PATCH 1/3] config: deprecate/drop crypto.gpg_path under gmime 2.6/3.0

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

[PATCH 2/3] clean up use of constants in g_mime_multipart_ wrappers

When compiling as C code (instead of C++) against gmime 3.0, gcc gives errors like the following: error: invalid conversion from ‘int’ to ‘GMimeDecryptFlags’ [-fpermissive] so use explicit *_NONE values instead. --- util/gmime-extra.h | 4 ++-- 1 file changed, 2 insertions(+), 2

[PATCH 3/3] crypto: Avoid explicit handling of GMimeCryptoContext in gmime 3.0

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

[PATCH 2/2] Add additional munged reply-to tests

The reply-to munging code might behave differently whether there's an exact match on the strings or not, or whether the string is a raw addr-spec instead of an name-addr. These tests cover those variations (i also had to tweak json output further below when this new test was added). ---

[PATCH 1/2] Ensure that "notmuch reply" succeeds during testing.

In some (bad!) cases, "notmuch reply" might fail, or might even segfault. If this happens, it indicates a bug, and the test suite should notice it. --- test/T220-reply.sh | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/test/T220-reply.sh

[PATCH] remove boolean "first" argument from format_part_sprinter

This argument seems to be unused, and format_part_sprinter isn't required to meet any specific API so it seems cleaner and simpler to drop it. --- notmuch-client.h | 2 +- notmuch-reply.c | 2 +- notmuch-show.c | 8 3 files changed, 6 insertions(+), 6 deletions(-) diff --git

Re: [PATCH] emacs: change default for notmuch-crypto-process-mime to t

On Mon 2017-07-10 20:48:40 -0400, Brian Sniffen wrote: > Gpg is exposed to some zip bomb problems last I looked. But the worst > that could do is fill your disk or crash your Emacs, right? And I > suspect the MIME library exposes similar issues in quantity. Could you point to the zip bomb

Re: [PATCH] emacs: change default for notmuch-crypto-process-mime to t

On Sun 2017-07-09 07:46:14 -0300, David Bremner wrote: > There are some cases like remote usage where this might cause > problems, but those users can easily customize the variable. The > inconvenience seems to be outweighed by the security benefit for most > users. lgtm. i'm not sure that this

Re: [PATCH 16/23] cli: generalize use of GMIME_SIGNATURE_{ERROR, STATUS} to gmime-3

On Sat 2017-06-03 14:47:47 -0300, David Bremner wrote: > @@ -376,6 +376,33 @@ format_signature_errors (sprinter_t *sp, GMimeSignature > *signature) > > do_format_signature_errors (sp, key_map, ARRAY_SIZE(key_map), errors); > } > +#else > +static void > +format_signature_errors (sprinter_t

Re: [PATCH 07/23] test/crypto: mark extra space in userid as a bug in gmime-2.6

On Wed 2017-07-05 23:26:18 +0300, Tomi Ollila wrote: > On Sat, Jun 03 2017, David Bremner wrote: > >> I can't see the space in the output of gpg -K --with-colons [...] > You could add a variable which is set to ' ' when gmime_2 is used and '' > when gmime_3 is used and insert that just like

finding incoming messages in threads in which i've participated [was: Re: find threads where I and Jian participated but not Dave]

Hey all-- I really appreciate the thought and experimentation and research that's gone into this thread! On Thu 2017-06-22 17:00:58 -0700, Matt Armstrong wrote: > # All threads in which I participate get tag:participated > # 1) Find all threads with a message tagged new > # (finding all

Re: find threads where I and Jian participated but not Dave

On Wed 2017-06-21 13:04:53 -0700, Matt Armstrong wrote: > For what it is worth, I've found this idea from Daniel intriguing and > pretty useful in practice: > > "show me threads in which i've participated, where there are some >messages flagged with 'inbox'" > > I implement it like this in

Re: [PATCH 4/5] fix wrong printf formatting of signed/unsigned integers

this series up to patch 4 LGTM, and seem uncontroversial. patch 5 adds FIXMEs that should probably actually be fixed, though, rather than just flagged. Thanks to Piotr for identifying these issues and suggesting the cleanup. --dkg ___ notmuch

Re: find threads where I and Jian participated but not Dave

On Tue 2017-06-13 20:31:19 -0300, David Bremner wrote: > Xu Wang writes: > >> I bump this. Actually more simple than that, how to search for thread >> in which I have participated and Jian has participated? Excluding >> threads in which Dave participated is perhaps more

Re: [patch v3 06/12] lib: index message files with duplicate message-ids

On Sun 2017-06-04 09:32:29 -0300, David Bremner wrote: > The corresponding xapian document just gets more terms added to it, > but this doesn't seem to break anything. Values on the other hand get > overwritten, which is a bit annoying, but arguably it is not worse to > take the values (from,

Re: [PATCH 2/3] devel/schemata: describe version 4

On Wed 2017-05-31 08:45:34 -0300, David Bremner wrote: > Not all keys will necessarily be generated with a given version of gmime. > --- > devel/schemata | 33 ++--- > 1 file changed, 26 insertions(+), 7 deletions(-) > > diff --git a/devel/schemata b/devel/schemata >

Re: [PATCH 2/2] exit lingering gpg agents at the end of relevant tests

On Tue 2017-05-23 21:54:25 +0300, Tomi Ollila wrote: > Since gnupg 2.1.20, gpg-agent no longer shut itself down when > $GNUPGHOME directory is removed. > > Add exit hooks to the test modules which execute `gpgconf --kill all` > > Add exit hooks to execute `gpgconf --kill all` in the modules that >

Re: changing behaviour of notmuch show --part=1

On Mon 2017-05-22 07:32:17 -0300, David Bremner wrote: > The current behaviour of "notmuch show --part=1 --raw" is somewhat > peculiar. This is supposed to be the message body, but if the message is > multipart, it also includes the headers. This seems to be a direct > translation of an

RE: Upcoming GMime 3.0 changes

On Tue 2017-05-09 10:37:30 -0300, David Bremner wrote: > Just for the record, I have some patches in progress for porting to > gmime-3.0. The main issue is the multiplicity of memory management > models involved. I think the gmime 3.0 approach of using more stock glib > memory management makes

Re: [RFC patch 2/2] lib: index message files with duplicate message-ids

On Thu 2017-03-16 20:34:22 -0400, David Bremner wrote: > Daniel Kahn Gillmor <d...@fifthhorseman.net> writes: >> 0) what happens when one of the files gets deleted from the message >> store? do the terms it contributes get removed from the index? > > That's a go

Re: [RFC patch 2/2] lib: index message files with duplicate message-ids

On Wed 2017-03-15 21:57:28 -0400, David Bremner wrote: > The corresponding xapian document just gets more terms added to it, > but this doesn't seem to break anything. this is an interesting suggestion. thanks for proposing it! A couple questions: 0) what happens when one of the files gets

Re: [RFE] Call `gpg --recv-keys` asynchronously

On Tue 2017-02-28 12:35:05 -0800, Steven Allen wrote: > Currently, notmuch fetches keys synchronously. This can be *very* slow > (I fetch keys over tor) and locks up emacs for the duration. Therefore, > this fetch really should be asynchronous. > > Unfortunately, getting this to work well (i.e.

Re: [PATCH 3/3] test: move GNUPGHOME to TEST_TMPDIR

On Mon 2017-02-27 16:26:50 -0800, David Bremner wrote: > We already use this directory for dtach sockets, so it makes sense to > put gnupg sockets there as well. There doesn't seem to be a clean way > to put a fully functional socket in a different location than > GNUPGHOME. LGTM. Thanks for

Re: [PATCH 2/2] test: use gpgconf --create-socketdir if available

On Tue 2017-02-14 16:42:39 -0500, David Bremner wrote: > This enables the shortened socket pathes in /run or equivalent. The > explicit call to gpgconf is needed for nonstandard GNUPGHOME settings. For the current GnuPG 2.1.18, this pair of patches looks reasonable to me, and it should indeed

help wanted: "notmuch count property:foo" as distinct from "notmuch count property:foo=bar"

in lib/database.cc, we have this FIXME in a comment: * Mail document * - * A mail document is associated with a particular email message. It * is stored in one or more files on disk (though only one has its * content indexed) and is uniquely identified by its "id" field *

Re: [PATCH] [EMACS] Adjust notmuch-crypto gpg call-process function

On Tue 2017-01-03 21:55:48 -0500, John Byrnes wrote: > I'm running the latest NixOS and noticed that the system does not > install gpgv1 by default. This means that the only gpg binary available > is the gpg2 binary. > > I found that notmuch-crypto.el hardcodes the GnuPG binary as gpg. I >

Re: converting attachments to text

On Tue 2017-01-03 02:27:23 -0500, Bart Bunting wrote: > I'm blind so use emacspeak as my primary interface. Having an easy way > to convert the notmuch attachments to text other than saving to a file > and processing them would greatly speed up my workflow. I use notmuch-emacs, and frequently

Re: [PATCH] tests: account for varying-size OpenPGP signatures

On Wed 2016-11-23 11:59:38 -0500, David Bremner wrote: > there are a bunch of sed oneliners (or perl equivalent) collected in > test-lib.sh as functions test_*_sanitize. I wonder if that would be > worthwhile here, to have one place to update regexps etc... Something > in the style of

[PATCH v2] tests: account for varying-size cryptographic signatures

GnuPG 2.1.16 is now injecting the full issuer fingerprint in its signatures, which makes them about 32 octets larger when ascii-armored. This change in size means that the size of the MIME parts will vary depending on the version of gpg that the user has installed. at any rate, the signature

Re: Bug#842291: notmuch processes frequently stuck in select()

Control: affects 842291 + gpgsm dirmngr On Wed 2016-11-23 03:50:40 -0500, David Bremner wrote: > David Bremner writes: > >> Brian May writes: >>> strace shows notmuch looping in select. >>> >>> select(10, [9], [], NULL, {1, 0}) = 0 (Timeout) >>>

[PATCH] tests: account for varying-size OpenPGP signatures

GnuPG 2.1.16 is now injecting the full issuer fingerprint in its signatures, which makes them about 32 octets larger when ascii-armored. This change in size means that the size of the MIME parts will vary depending on the version of gpg that the user has installed. at any rate, the signature

Re: T350 test failures with gnupg-2.1.16

On Tue 2016-11-22 15:49:37 -0500, Daniel Kahn Gillmor wrote: > On Tue 2016-11-22 14:22:09 -0500, Marius Bakke wrote: >> T350-crypto: Testing PGP/MIME signature verification and decryption >> PASS emacs delivery of signed message >> FAIL signature verification >>

Re: T350 test failures with gnupg-2.1.16

On Tue 2016-11-22 14:22:09 -0500, Marius Bakke wrote: > T350-crypto: Testing PGP/MIME signature verification and decryption > PASS emacs delivery of signed message > FAIL signature verification > --- T350-crypto.2.expected 2016-11-22 18:59:48.341851653 + > +++

Re: [PATCH v2 0/4] Add refresh all buffers functionality

On Sun 2016-09-25 03:32:08 -0400, Tomi Ollila wrote: > 2) then, minor commit message related comment: if there is going to be v3, > in id:20160924200735.25425-2-...@adirat.com adi mentioned 'next patches' > -- those are not patches (anymore) when commits are made, so it would be > better to

Re: v3 of message properties patches

On Sat 2016-08-06 09:52:30 -0400, David Bremner wrote: > This obsoletes > > id:1470184228-12517-1-git-send-email-da...@tethera.net > > In particular it fixes the compile errors (boo), and adds dkg's > has: queries, with minimal doc and tests. I've been running this series of patches since

Re: [PATCH 2/2] emacs: postpone/resume support

On Sun 2016-09-11 08:05:20 -0400, David Bremner wrote: > Mark Walters writes: > >> This provides preliminary support for postponing and resuming in the >> emacs frontend. On postponing it uses notmuch insert to put the >> message in the notmuch database; resume gets the

Re: [PATCH v2] emacs: reply: remove wrong sig/enc status buttons

Hi Mark-- On Tue 2016-09-13 00:12:19 +0200, Mark Walters wrote: > This stopps the (usually incorrect) sigstatus and encstatus buttons > appearing when replying in emacs, and updates the test suite to match. > > Overriding the status button functions is a little unusual but much > less intrusive

Re: [PATCH] emacs: reply: remove wrong sig/enc status buttons

On Mon 2016-09-12 03:11:44 +0200, David Bremner wrote: > Mark Walters writes: > >> This stopps the (usually incorrect) sigstatus and encstatus buttons >> appearing when replying in emacs, and updates the test suite to match. >> >> Overriding the status button functions

[PATCH] clean up spelling

--- NEWS | 4 ++-- doc/man1/notmuch-dump.rst| 2 +- doc/man1/notmuch-insert.rst | 4 ++-- doc/man1/notmuch-restore.rst | 2 +- doc/man5/notmuch-hooks.rst | 2 +- 5 files changed, 7 insertions(+), 7 deletions(-) diff --git a/NEWS b/NEWS index dbb9298..578c99c 100644

Re: State of S/MIME support (emacs)

On Thu 2016-09-01 15:32:07 -0400, Neale Pickett wrote: > I just set up notmuch an hour ago and it seems like exactly what I need > to better perform my project management job. Except I get a lot of > S/MIME stuff. > > Web searching tells me there have been various attempts for S/MIME > support.

Re: [PATCH v4 01/16] add util/search-path.{c, h} to test for executables in $PATH

On Fri 2016-08-12 03:38:53 -0400, David Bremner wrote: > Daniel Kahn Gillmor <d...@fifthhorseman.net> writes: > >>> Should we distinguish between relative and absolute paths here? I can't >>> think of any security implications, but I'm wondering if a relative path &

Re: [PATCH v4 01/16] add util/search-path.{c, h} to test for executables in $PATH

On Fri 2016-08-12 01:51:16 -0400, David Bremner wrote: > Daniel Kahn Gillmor <d...@fifthhorseman.net> writes: > >> This is a utility function we can use to see whether an executa> >> +if (strchr (exename, '/')) { >> +if (0 == access (exename, X_OK)) >

<    6   7   8   9   10   11   12   13   14   15   >