Daniel Kahn Gillmor writes:
> 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.
pushed.
d
_
Daniel Kahn Gillmor writes:
> "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
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 and definitely addresses all my concerns.
I'm stoked to see that the fi
Daniel Kahn Gillmor writes:
> 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
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 in https://bugs.debian.org/
Comming back after a long time (sorry for the wait).
I now changed the binding for notmuch_database_get_config_list into a
generator. It is called get_configs in the python bindings (the "s"
should indicate the iterable/generator nature like for dict.items or
dict.keys).
Tests and the set_config
This mimics the behaviour of the underlying C function more closely as
it also does not store all values in memory.
---
bindings/python/notmuch/database.py | 30 --
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/bindings/python/notmuch/database.py b/bi
The tests where adopted from the tests for the corresponding C functions
in test/T590-libconfig.sh.
---
test/T390-python.sh | 68 +
1 file changed, 68 insertions(+)
diff --git a/test/T390-python.sh b/test/T390-python.sh
index a93a7f34..725a00c9
The C functions notmuch_database_get_config,
notmuch_database_get_config_list and notmuch_database_set_config are
part of the official C bindings. So there should also be some python
bindings for them.
Also they are the only way to access the named queries introduced in
b9bf3f44.
The interface
It makes the function a little more intuitive to use and does not
diverge much from the original function signature.
Also an example is added to the docstring.
---
bindings/python/notmuch/database.py | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/bindings/pyth
The old name has a bit of a feeling of hungarian notation. Also many
generators in the core are named with the suffix "s" to indicate
iterables: dict.items, dict.keys for example.
---
bindings/python/notmuch/database.py | 18 ++
test/T390-python.sh | 12 ++
---
test/T390-python.sh | 13 +
1 file changed, 13 insertions(+)
diff --git a/test/T390-python.sh b/test/T390-python.sh
index c6f395e4..312d61e8 100755
--- a/test/T390-python.sh
+++ b/test/T390-python.sh
@@ -142,4 +142,17 @@ cat <<'EOF' >EXPECTED
EOF
test_expect_equal_file EXPECTED
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
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
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:
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
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 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,
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
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's other
> identity assertions (the "t
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
30 matches
Mail list logo
