The notmuch indexing subcommands ("new", "insert", and "reindex") now
have a --decrypt option that takes an argument (the decryption
policy), since the session-keys patches have landed.
But the viewing subcommands ("show" and "reply") have their
traditional --decrypt option that (as a boolean) nee
We also expand tab completion for it, and update T357 to match.
Make use of the bool-to-keyword backward-compatibility feature.
---
completion/notmuch-completion.bash | 6 +-
doc/man1/notmuch-show.rst | 37 +
notmuch-show.c | 2
This brings the --decrypt argument to "notmuch reply" into line with
the other --decrypt arguments (in "show", "new", "insert", and
"reindex"). This patch is really just about bringing consistency to
the user interface.
---
completion/notmuch-completion.bash | 2 +-
doc/man1/notmuch-reply.rst
We might change some notmuch command line tools that used to be
booleans into keyword arguments.
In that case, there are some legacy tools that will expect to be able
to do "notmuch foo --bar" instead of "notmuch foo --bar=baz".
This patch makes it possible to support that older API, while
provid
---
debian/control | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/control b/debian/control
index f644695b..bf7eb647 100644
--- a/debian/control
+++ b/debian/control
@@ -28,7 +28,7 @@ Build-Depends:
gpgsm ,
gnupg ,
bash-completion (>=1.9.0~)
-Standards-Version: 4.1
We adopt a pythonic idiom here with an optional argument, rather than
exposing the user to the C indexopts object directly.
This now includes a simple test to ensure that the decrypt_policy
argument works as expected.
---
bindings/python/notmuch/database.py | 45 ++
When i'm trying to understand a message signature, i care that i know
who it came from (the "validity" of the identity associated with the
key), *not* whether i'm willing to accept the keyholder's other
identity assertions (the "trust" associated with the certificate).
We've been reporting User ID
Bremner pointed out to me that v2 of this patch doesn't work with 2.6,
and that the name of the function should be
g_mime_certificate_get_valid_userid, instead of
g_mime_get_certificate_valid_userid.
Also, he asked that it be built against the "release" branch, since
it's important there, too.
So
When i'm trying to understand a message signature, i care that i know
who it came from (the "validity" of the identity associated with the
key), *not* whether i'm willing to accept the keyholder's other
identity assertions (the "trust" associated with the certificate).
We've been reporting User ID
On Fri 2017-12-08 14:36:04 -0400, David Bremner wrote:
> Daniel Kahn Gillmor writes:
>
>> @@ -478,9 +478,10 @@ fi
>> # we need to have a version >= 2.6.5 to avoid a crypto bug. We need
>> # 2.6.7 for permissive "From " header handling.
>> GMIME_MI
On Thu 2017-12-07 00:20:12 -0800, Jameson Graef Rollins wrote:
> On Mon, Dec 04 2017, David Bremner wrote:
>> Pushed patches 1 to 6. I seem to recall 7 and 8 basically adressed
>> concerns/suggestions Jamie had, so I'm hoping he can have a quick look
>> at those.
>
> Yes, this new series is great
On Wed 2017-11-29 23:20:35 -0500, Daniel Kahn Gillmor wrote:
> When i'm trying to understand a message signature, i care that i know
> who it came from (the "validity" of the identity associated with the
> key), *not* whether i'm willing to accept the keyholder'
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 tun
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 s
we also include --decrypt=auto in the tab completion.
---
completion/notmuch-completion.bash | 6 +++---
doc/man1/notmuch-insert.rst| 16 ++--
doc/man1/notmuch-new.rst | 10 +++---
doc/man1/notmuch-reindex.rst | 23 ++-
4 files changed,
Now that the range of sensible decryption policies has come into full
view, we take a bit of space to document the distinctions.
Most people will use either "auto" or "true" -- but we provide "false"
and "nostash" to handle use cases that might reasonably be requested.
Note also that these can be
We adopt a pythonic idiom here with an optional argument, rather than
exposing the user to the C indexopts object directly.
---
bindings/python/notmuch/database.py | 45 +++--
bindings/python/notmuch/globals.py | 5 +
2 files changed, 48 insertions(+), 2 delet
When showing a message, if the user doesn't specify --decrypt= at all,
but a stashed session key is known to notmuch, notmuch should just go
ahead and try to decrypt the message with the session key (without
bothering the user for access to their asymmetric secret key).
The user can disable this a
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.
---
doc/man1/notmuch-config.rst | 11 ---
lib/index.cc | 3 ++-
lib/indexopts.c
The first part of the session-keys series has already landed --
thanks to everyone who reviewed it and shepherded it on its way!
This is a respin of the remaining patches in the series, introducing
very minor changes from the previous series: typo corrections, and a
fix to the test suite to mark s
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.
---
lib/index.cc | 2 +-
lib/indexopts.c | 21 +++--
lib/notmuch.h
There are some situations where the user wants to get rid of the
cleartext index of a message. For example, if they're indexing
encrypted messages normally, but suddenly they run across a message
that they really don't want any trace of in their index.
In that case, the natural thing to do is:
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.
---
lib/index.cc | 2 +-
lib/indexopts.c | 10 +-
lib/notmuch.h| 8
notmuch-client.h | 4 ++--
notmuch.c| 12 +
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 cha
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
If the user doesn't specify --decrypt= at all, but a stashed session
key is known to notmuch, when replying to an encrypted message,
notmuch should just go ahead and decrypt.
The user can disable this at the command line with --decrypt=false,
though it's not clear why they would ever want to do th
The stashed session keys are stored internally as notmuch properties.
So a user or developer who is reading about those properties might
want to understand how they fit into the bigger picture.
Note here that decrypting with a stored session key no longer needs
-decrypt for "notmuch show" and "not
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
co
On Thu 2017-11-30 04:40:43 -0500, Daniel Kahn Gillmor wrote:
> This makes lintian stop complaining about:
>
> W: elpa-notmuch: wrong-section-according-to-package-name elpa-notmuch => lisp
I'm withdrawing this patch for consideration. I'm convinced by
bremner's argument
Hi Brian--
On Wed 2017-12-06 10:00:19 -0500, Brian Sniffen wrote:
> Okay, https://github.com/briansniffen/notmuch/tree/nmweb is now rebased
> onto the notmuchmail.org head as of this morning. All of the changes
> are under contrib/notmuch-web.
thanks for doing this!
traditionally, we've encou
Named queries don't work without Xapian FieldProcessor. Rather than
silently skipping them, we should explictly mark them as broken when
building against an older version of Xapian.
---
test/T600-named-queries.sh | 33 -
1 file changed, 20 insertions(+), 13 deletio
If we're building against a version of Xapian that doesn't offer
retrying the lock, we should be honest and describe the tests as
broken, rather than marking them as missing a test prerequisite.
missing test prerequisites should be for specific components of the
test harness that are missing, not
We have several places where tests are skipped or marked as though
some test suite prereqs are missing, but in fact are due to building
against older versions of libraries that don't support certain
features.
This series tries to be more honest about some of those tests by
marking them as broken,
Previously, the test suite had simply silently skipped the absolute
date test if we're using an archaic version of Xapian. For
correctness, we should instead mark the test as broken.
This also changes from string to numeric comparison when checking
NOMTUCH_HAVE_XAPIAN_FIELD_PROCESSOR for consiste
On Mon 2017-12-04 21:59:18 -0400, David Bremner wrote:
> Pushed patches 1 to 6. I seem to recall 7 and 8 basically adressed
> concerns/suggestions Jamie had, so I'm hoping he can have a quick look
> at those.
to be fair, i thought Jamie's concerns were correct -- the normalized
interface is better
python2 is going to be deprecated, and python3-sphinx is available all
the way back to oldoldstable. let's use the more modern version.
To make this work and still ship the manpages, tell ./configure to
prefer python3 over python, if it exists.
---
configure | 2 +-
debian/control | 2 +-
2
On Tue 2017-12-05 13:40:27 -0500, Daniel Kahn Gillmor wrote:
> If the version of GMime we're building against doesn't support session
> key extraction or re-use, mark the tests that rely on session key
> capabilities as known-broken.
>
> This should resolve test suite fail
ryption.sh
@@ -183,6 +183,9 @@ EOF
notmuch reindex --try-decrypt id:simple-encryp...@crypto.notmuchmail.org
output=$(notmuch search sekrit)
expected='thread:0001 2016-12-22 [1/1] Daniel Kahn Gillmor;
encrypted message (encrypted inbox unread)'
+if [ $NOTMUCH_HAVE_GMIME_SESSIO
On Mon 2017-12-04 21:30:00 -0400, David Bremner wrote:
> Daniel Kahn Gillmor writes:
>
>> No minor changes were necessary to become compliant with Debian policy
>> version 4.1.1, so this is basically a freebie.
>
> pushed 2,3,4. Waiting for you and Tomi to reach a fixed po
On Mon 2017-12-04 10:44:40 -0500, Daniel Kahn Gillmor wrote:
> But maybe you'll find my revised version
> (id:20171204154333.27505-1-...@fifthhorseman.net) mitigates the error
> you're pointing out?
sorry, that should be id:20171204184310.17125-1-...@fifthhorseman.net --
the
"notmuch help" doesn't mention "notmuch-emacs-mua" even though we
support it through the try_external_command() mechanism.
In addition, "notmuch help emacs-mua" doesn't work, even though we
ship the appropriate manpage.
This changeset fixes both of these problems.
---
configure | 1 +
notmuch.c
On Sun 2017-12-03 15:26:32 +0200, Tomi Ollila wrote:
> My thought was that even though user may compile notmuch without emacs
> support (and notmuch-emacs-mua not installed) we would be hinting
> `notmuch emacs-mua` command to exist.
Currently, if the user *does* compile with emacs support, and i
On Sun 2017-12-03 15:35:04 +0200, Tomi Ollila wrote:
> On Thu, Nov 30 2017, Daniel Kahn Gillmor wrote:
>
>> On Thu 2017-11-30 04:40:39 -0500, Daniel Kahn Gillmor wrote:
>>> python2 is going to be deprecated, and python3-sphinx is available all
>>> the way back to old
On Thu 2017-11-16 08:53:14 -0400, David Bremner wrote:
> I'd be happier if we didn't further entrench the text format in the test
> suite. How hard would it be to use json output (+maybe python?) here?
json output seems clunkier to me, and i don't think it's necessary for
the purposes of these te
On Thu 2017-11-16 09:06:09 -0400, David Bremner wrote:
> I think this new bindings functionality needs a test.
agreed, the python bindings do need to be added to the test suite (this
is also true in the newer version of the series).
I'm happy to add those tests as a condition of getting the pytho
On Thu 2017-11-30 03:59:46 -0500, Daniel Kahn Gillmor wrote:
> @@ -454,10 +487,19 @@ class Database(object):
>:attr:`STATUS`.READ_ONLY_DATABASE
>Database was opened in read-only mode so no message can
>
On Thu 2017-11-30 03:59:29 -0500, Daniel Kahn Gillmor wrote:
> +hexidecimal representation of the algorithm-specific key. For
ugh, this should be hexadecimal, not hexidecimal.
This is fixed in my gitlab session-keys branch [0], but doesn't seem
worth re-posting the entire se
On Thu 2017-11-30 09:44:19 -0400, David Bremner wrote:
> Floris Bruynooghe writes:
>
>> This also has the binary question problem, is this returned as bytes or
>> as str? Current Python bindings seem to go for .decode('utf-8',
>> errors='ignore') afaik which is somewhat lossy.
>>
>
> IMHO there's
On Thu 2017-11-30 11:08:05 +0200, Tomi Ollila wrote:
> On Thu, Nov 30 2017, Daniel Kahn Gillmor wrote:
>
>> On Thu 2017-10-26 18:27:51 -0400, Daniel Kahn Gillmor wrote:
>>> "notmuch help" doesn't mention "notmuch-emacs-mua" even though we
>>>
On Thu 2017-11-30 04:40:39 -0500, Daniel Kahn Gillmor wrote:
> python2 is going to be deprecated, and python3-sphinx is available all
> the way back to oldoldstable. let's use the more modern version.
> ---
> debian/control | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion
On Thu 2017-11-30 08:01:18 -0400, David Bremner wrote:
> Daniel Kahn Gillmor writes:
>
>> The following patch series should be fairly unobjectionable cleanup of
>> the debian packaging for notmuch.
>>
>> Let me know if you think there are problems with any of it.
python2 is going to be deprecated, and python3-sphinx is available all
the way back to oldoldstable. let's use the more modern version.
---
debian/control | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/control b/debian/control
index 20b8a2db..3a624fdc 100644
--- a/debi
No minor changes were necessary to become compliant with Debian policy
version 4.1.1, so this is basically a freebie.
---
debian/control | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/control b/debian/control
index bb88b0f7..51129886 100644
--- a/debian/control
+++ b/de
This makes lintian stop complaining about:
W: elpa-notmuch: wrong-section-according-to-package-name elpa-notmuch => lisp
---
debian/control | 1 +
1 file changed, 1 insertion(+)
diff --git a/debian/control b/debian/control
index 51129886..cff610cf 100644
--- a/debian/control
+++ b/debian/control
---
debian/changelog | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 67282a07..decef1e9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -836,7 +836,7 @@ notmuch (0.9~rc2-1) experimental; urgency=low
- New SON
The following patch series should be fairly unobjectionable cleanup of
the debian packaging for notmuch.
Let me know if you think there are problems with any of it.
--dkg
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mail
Move transitional package to to "oldlibs/optional"
This resolves two lintian warnings:
W: notmuch-emacs: transitional-package-should-be-oldlibs-optional oldlibs/extra
W: notmuch-emacs: priority-extra-is-replaced-by-priority-optional
---
debian/control | 1 -
1 file changed, 1 deletion(-)
diff -
If (for whatever reason) we don't get a decrypt_result back, or it's
not structured the way we expect it to be, we shouldn't choke on it.
---
mime-node.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/mime-node.c b/mime-node.c
index e1aca969..7c8b2602 100644
---
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 th
This flag should make it easier to write the code for session-key
handling.
Note that this only works for GMime 2.6.21 and later (the session key
interface wasn't available before then). It should be fine to build
the rest of notmuch if this functionality isn't available.
Note that this also add
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 tun
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.
---
lib/index.cc | 2 +-
lib/indexopts.c | 10 +-
lib/notmuch.h| 8
notmuch-client.h | 4 ++--
notmuch.c| 12 +
Now that the range of sensible decryption policies has come into full
view, we take a bit of space to document the distinctions.
Most people will use either "auto" or "true" -- but we provide "false"
and "nostash" to handle use cases that might reasonably be requested.
Note also that these can be
If the user doesn't specify --decrypt= at all, but a stashed session
key is known to notmuch, when replying to an encrypted message,
notmuch should just go ahead and decrypt.
The user can disable this at the command line with --decrypt=false,
though it's not clear why they would ever want to do th
When showing a message, if the user doesn't specify --decrypt= at all,
but a stashed session key is known to notmuch, notmuch should just go
ahead and try to decrypt the message with the session key (without
bothering the user for access to their asymmetric secret key).
The user can disable this a
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.
---
doc/man1/notmuch-config.rst | 11 ---
lib/index.cc | 3 ++-
lib/indexopts.c
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.
---
lib/index.cc | 2 +-
lib/indexopts.c | 21 +++--
lib/notmuch.h
we also include --decrypt=auto in the tab completion.
---
completion/notmuch-completion.bash | 6 +++---
doc/man1/notmuch-insert.rst| 16 ++--
doc/man1/notmuch-new.rst | 10 +++---
doc/man1/notmuch-reindex.rst | 23 ++-
4 files changed,
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 cha
This is the second revision of the session keys series. the earlier
version of this series can be found following
id:20171025065203.24403-1-...@fifthhorseman.net.
This version addresses the ideas and critiques raised on list about
the first version.
In particular:
* ./configure now detects and
The stashed session keys are stored internally as notmuch properties.
So a user or developer who is reading about those properties might
want to understand how they fit into the bigger picture.
Note here that decrypting with a stored session key no longer needs
-decrypt for "notmuch show" and "not
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
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 s
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
co
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 pr
!
diff --git a/test/corpora/crypto/simple-encrypted
b/test/corpora/crypto/simple-encrypted
new file mode 100644
index ..6869972d
--- /dev/null
+++ b/test/corpora/crypto/simple-encrypted
@@ -0,0 +1,36 @@
+From: Daniel Kahn Gillmor
+To: d...@fifthhorseman.net
+Subject: encrypted message
+Date
We adopt a pythonic idiom here with an optional argument, rather than
exposing the user to the C indexopts object directly.
---
bindings/python/notmuch/database.py | 46 +++--
bindings/python/notmuch/globals.py | 5
2 files changed, 49 insertions(+), 2 deleti
If you've got a notmuch dump that includes stashed session keys for
every decrypted message, and you've got your message archive, you
should be able to get back to the same index that you had before.
Here we add a simple test that give some flavor of how that works.
---
test/T357-index-decryption
There are some situations where the user wants to get rid of the
cleartext index of a message. For example, if they're indexing
encrypted messages normally, but suddenly they run across a message
that they really don't want any trace of in their index.
In that case, the natural thing to do is:
On Thu 2017-11-16 08:40:41 -0400, David Bremner wrote:
> Daniel Kahn Gillmor writes:
>
>> The new "auto" decryption policy is not only good for "notmuch show"
>> and "notmuch reindex". It's also useful for indexing messages --
>>
On Thu 2017-10-26 18:27:51 -0400, Daniel Kahn Gillmor wrote:
> "notmuch help" doesn't mention "notmuch-emacs-mua" even though we
> support it through the try_external_command() mechanism.
>
> In addition, "notmuch help emacs-mua" doesn't
On Thu 2017-10-26 18:28:12 -0400, Daniel Kahn Gillmor wrote:
> ---
> completion/notmuch-completion.bash | 2 +-
> notmuch.c | 2 ++
> 2 files changed, 3 insertions(+), 1 deletion(-)
Ping on this patch as well. I think this should be safe and sim
When i'm trying to understand a message signature, i care that i know
who it came from (the "validity" of the identity associated with the
key), *not* whether i'm willing to accept the keyholder's other
identity assertions (the "trust" associated with the certificate).
We've been reporting User ID
On Tue 2017-11-28 23:46:11 +0100, Ruben Pollan wrote:
> Message.get_property (prop) returns a string with the value of the property
> and
> Message.get_properties (prop, exact=False) returns a list [(key, value)]
This looks like a sensible approach to me. I'd be curious to hear what
others think
On Wed 2017-11-15 23:29:54 +0100, Ruben Pollan wrote:
> Message.get_property (prop) returns a string with the value of the property.
Upon review, this is actually insufficient for making robust use of the
session-key series :(
In particular, it only returns the first value for the session key
ret
Hi meskio--
On Wed 2017-11-15 23:41:28 +0100, meskio wrote:
> Nice feature. I'm using it and it works fine. I notice some speed up,
> improving
> the painfulness of reading long encrypted threads in alot. And I like to
> don't
> be able to have around my old private keys.
cool, i'm glad it's
On Tue 2017-11-14 09:13:52 -0400, David Bremner wrote:
> Daniel Kahn Gillmor writes:
>
>> If you've got a notmuch dump that includes stashed session keys for
>> every decrypted message, and you've got your message archive, you
>> should be able to get back to
Hi Bremner--
Thanks for the review!
On Tue 2017-11-14 09:02:08 -0400, David Bremner wrote:
> Since you wrote this, I've deprecated GMime 2.6. I'm not sure that
> changes anything here, but seems worth mentioning
well, i'm happy to hear that -- i've got no problem with deprecating
GMime 2.6, and
On Sun 2017-11-12 11:51:11 +0800, Daniel Kahn Gillmor wrote:
> On Sat 2017-11-11 15:31:36 -0800, Jameson Graef Rollins wrote:
>> I haven't decided what's the best way to do that yet, but something
>> like the following happening automatically at inbox view might do the
On Sat 2017-11-11 15:14:03 -0800, Jameson Graef Rollins wrote:
> On Wed, Oct 25 2017, Daniel Kahn Gillmor wrote:
>> diff --git a/util/crypto.h b/util/crypto.h
>> index b23ca747..dc95b4ca 100644
>> --- a/util/crypto.h
>> +++ b/util/crypto.h
>> @@ -16,7 +16,8
On Sat 2017-11-11 15:31:36 -0800, Jameson Graef Rollins wrote:
> I have reviewed and tested this series, and it seems solidly
> implemented and very well motivated. I have been using it regularly
> for a couple weeks now and have found no issues with it's usage, and
> have noticed the considerable
On Wed 2017-10-25 02:51:45 -0400, Daniel Kahn Gillmor wrote:
> Now that cleartext indexing is merged, let's add the ability to stash
> session keys!
I'd really appreciate feedback on this series. It works for me, and i'm
using it. I don't want this to take another two
On Mon 2017-10-30 12:16:25 -0400, Antoine Beaupré wrote:
> I think that assumption should be made clear in the documentation,
> because "security of your index" means nothing to me. Explicitly mention
> FDE as an example may be a good start.
again, i'm not convinced that "full disk" encryption is
On Mon 2017-10-30 08:46:12 -0400, Antoine Beaupré wrote:
> On 2017-10-22 11:36:34, Daniel Kahn Gillmor wrote:
>> + Note that the contents of the index are sufficient to roughly
>> + reconstruct the cleartext of the message itself, so please ensure
>> + that the no
On Fri 2017-10-27 00:04:21 -0400, Brian Sniffen wrote:
> With bleach integrated (all of five lines), I think this is safe enough
> to let random notmuch users run it.
hm, bleach might be a little too aggressive.
jrollins just pointed toward:
https://nmweb.evenmere.org/show/87innmvvam.fsf%40ligo.
On Fri 2017-10-27 00:04:21 -0400, Brian Sniffen wrote:
> Thanks! The part I'm happiest about is the speed:
amen, it feels very lightweight.
> Very careful examination would have shown that the em-dashes between
> author and subject were red for matches. Now matches are in italics.
cool. perha
"notmuch help" doesn't mention "notmuch-emacs-mua" even though we
support it through the try_external_command() mechanism.
In addition, "notmuch help emacs-mua" doesn't work, even though we
ship the appropriate manpage.
This changeset fixes both of these problems.
---
notmuch.c | 5 -
1 file
---
completion/notmuch-completion.bash | 2 +-
notmuch.c | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/completion/notmuch-completion.bash
b/completion/notmuch-completion.bash
index a0c3ac17..895fc554 100644
--- a/completion/notmuch-completion.bash
On Wed 2017-10-25 18:03:01 -0400, Brian Sniffen wrote:
> That's inspiring! Now there's a demo of nmweb at
>
> https://nmweb.evenmere.org/
this is very nice, Brian.
Your URL highlighter seems a bit trigger-happy though:
https://nmweb.evenmere.org/show/8760s7zr47.fsf%40zancas.localnet
I don't
est-lib-common.sh") started using a test specific
> backup directories under the build tree test directory. This was in
> error. Switch back to the old location, but using paths to the
> location instead of relying on current working directory.
>
> Reported by Daniel Kahn Gillm
801 - 900 of 1575 matches
Mail list logo