Daniel Kahn Gillmor writes:
> Not sure how to best
> represent that in nmbug -- but for now i've removed
> notmuch::needs-review and added notmuch::wip. bremner, let me know if
> you think i should have done something different.
I also marked the other two patches in the series as WIP; feel fre
On Wed, May 09 2018, David Bremner wrote:
> Prof Jayanth R Varma writes:
>
>> This patch modifies the function notmuch-tree-show-message-in in
>> notmuch-tree.el to split the window vertically while creating a
>> message pane in tree-mode if the window is wider than 160 (so that
>> after split
Tomi Ollila writes:
> On Wed, May 09 2018, David Bremner wrote:
>
>> Prof Jayanth R Varma writes:
>>
>>> This patch modifies the function notmuch-tree-show-message-in in
>>> notmuch-tree.el to split the window vertically while creating a
>>> message pane in tree-mode if the window is wider tha
On Wed, May 09 2018, Thomas Schneider wrote:
> This way, one can build for a different Ruby than $PATH/ruby
> (e. g. different versions, or Ruby in other paths).
LGTM.
Tomi
>
> Signed-off-by: Thomas Schneider
> ---
> bindings/Makefile.local | 2 +-
> configure | 11 ++-
Thomas Schneider writes:
> This way, one can build for a different Ruby than $PATH/ruby
> (e. g. different versions, or Ruby in other paths).
>
> Signed-off-by: Thomas Schneider
pushed to master.
d
___
notmuch mailing list
notmuch@notmuchmail.org
htt
Correctly fix the two outstanding tests so that the protected (hidden)
subject is properly reported.
---
notmuch-client.h | 2 +-
notmuch-reply.c| 4 +++-
notmuch-show.c | 11 +++
test/T356-protected-headers.sh | 3 ---
4 files changed, 11 i
Here we add several variant e-mail messages, some of which have
correctly-structured protected headers, and some of which do not. The
goal of the tests is to ensure that the right protected subjects get
reported.
---
test/T356-protected-headers.sh| 69 +++
...le-wr
This test scans for all the possible protected headers (including
bogus/broken ones) that are present in the protected-headers corpus,
trying to make sure that only the ones that are not broken or
malformed show up in a search after re-indexing.
---
test/T356-protected-headers.sh | 9 +
1
This makes it easier to reuse format_part_sigstatus_sprinter() when we
have other places that we want to display a signature status.
---
notmuch-show.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/notmuch-show.c b/notmuch-show.c
index 9871159d..f0be8060 100644
--- a/no
The mime node context (a per-message context) gains a cryptographic
status object, and the mime_node_t object itself can return a view on
that status to an interested party.
The status is not yet populated, and for now we can keep that view
read-only, so that it can only be populated/modified duri
When walking the MIME tree, if we discover that we are at the
cryptographic payload, then we would like to record at least the
Subject header.
In the future, we might want to record many other headers as well, but
for now we will stick with just the Subject.
See
https://dkg.fifthhorseman.net/blog
Traditionally, encrypted and signed e-mail covers only the body of the
message. New standards are emerging that are capable of protecting
the headers as well. In particular, Enigmail and an upcoming version
of K-9 mail both use the "Memory Hole" approach to encrypt the
Subject: header when sendin
Adding another test to ensure that we handle it gracefully when no
external subject is present.
---
test/T356-protected-headers.sh| 6
.../subjectless-protected-header.eml | 29 +++
2 files changed, 35 insertions(+)
create mode 100644
test/corpora/p
Unsigned encrypted mail shows up with a weird empty signature list.
If we successfully decrypted and there was no signature in it, we
should just not show a sigstatus at all.
The documentation for g_mime_decrypt_result_get_signatures says:
a GMimeSignatureList or NULL if the stream was not si
E-mail encryption and signatures reported by notmuch are at the MIME
part level. This makes sense in the dirty details, but for users we
need to have a per-message conception of the cryptographic state of
the e-mail. (see
https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html for more
discus
Up to this point, we've tested protected headers on messages that have
either been encrypted or signed, but not both.
This adds a couple tests of signed+encrypted messages, one where the
subject line is masked (outside subject line is "encrypted message")
and another where it is not (outside Subje
Make sure that we emit the correct cryptographic envelope status for
cleartext signed messages.
---
test/T356-protected-headers.sh| 11 ++-
.../signed-protected-header.eml | 29 +++
.../protected-headers/simple-signed-mail.eml | 28 +++
From: Jameson Graef Rollins
This makes it easier to write fairly compact, readable tests of json
output, without needing to sanitize away parts that we don't care
about.
Signed-off-by: Daniel Kahn Gillmor
---
test/json_check_nodes.py | 112 +++
test/test-lib
This flag indicates the intent of the client to protect the subject
line, which allows "notmuch reply" to safely emit the earlier
message's encrypted subject without risking leaking it in the clear in
the reply.
Obviously, it should only be used by a client that *will* protect the
subject line. T
This paves the way for emitting protected headers after verification
and decryption, because it means that the headers will only be emitted
after the body has been parsed.
---
notmuch-show.c| 6 +++---
test/T170-sexp.sh | 8
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git
Deliberately populate the message's cryptographic status while walking
the MIME tree from the CLI.
---
mime-node.c | 27 ---
1 file changed, 24 insertions(+), 3 deletions(-)
diff --git a/mime-node.c b/mime-node.c
index cbff95d1..6ecd121d 100644
--- a/mime-node.c
+++ b/mime
When indexing the cleartext of an encrypted message, record any
protected subject in the database, which should make it findable and
visible in search.
---
lib/index.cc | 42 ++
lib/message.cc | 8 +++
lib/notmuch-private.h
This allows MUAs that don't want to think about per-mime-part
cryptographic status to have a simple high-level overview of the
message's cryptographic state.
Sensibly structured encrypted and/or signed messages will work fine
with this. The only requirement for the simplest encryption + signing
i
This allows a clever UI frontend to mark whether a header was
protected (or not), and if it was protected, to show the details to
an interested user.
As before, we only handle Subject for now, but we might be able to
handle other headers in the future.
---
devel/schemata | 6
Rather than passing a boolean to indicate whether this is a reply to
format_headers_sprinter(), we use a flag field. This will be used
shortly to allow clients to indicate that they can responsibly protect
the subject line. This changeset has no functional change itself,
just modifying the types
Now that we can decrypt headers, we want to make sure that clients
using "notmuch reply" to prepare a reply don't leak cleartext in their
subject lines. In particular, the ["reply-headers"]["Subject"] should
by default show the external Subject.
---
test/T356-protected-headers.sh | 7 +++
1 f
Hi,
Gmailieer v0.8 has been released!
https://github.com/gauteh/gmailieer
Gmailieer provides fast email-fetching and two-way tag synchronization
between notmuch and GMail.
Changes:
* Allow custom tags to be ignored (when pushing), can be set with `gmi
set`.
* Bug fix in `gmi set`.
Re
If the number of session keys for a given message increased after
running "notmuch show" then we just learned something new that might
let us do automatic decryption. We should reindex this message using
our newfound knowledge.
---
notmuch-show.c | 19 +++
1 file changed, 19 inser
If the decryption policy is NOTMUCH_DECRYPT_TRUE, that means we want
to stash session keys in the database. Note that there is currently
no way from the command line to set it this way, though, so it is not
yet included in the test suite.
---
mime-node.c | 22 ++
1 file change
This function is a parallel to print_status_query() or
print_status_database(). Thanks to David Bremner for the suggestion!
---
notmuch-client.h | 5 +
status.c | 20
2 files changed, 25 insertions(+)
diff --git a/notmuch-client.h b/notmuch-client.h
index 0985a7
Thanks to David Bremner for this improved readability!
---
test/T357-index-decryption.sh | 10 +-
test/test-lib.sh | 5 +
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/test/T357-index-decryption.sh b/test/T357-index-decryption.sh
index 2b8e05b8..ad6c3616
The user can already do this manually, of course, but (a) it's nice to
have a convenience function, and (b) exposing this interface means
that someone more clever with a _notmuch_string_map_t than i am can
write a more efficient version if they like, and it will just
accelerate the users of the con
Add fancy new feature, which makes "notmuch show" capable of actually
indexing messages that it just decrypted.
This enables a workflow where messages can come in in the background
and be indexed using "--decrypt=auto". But when showing an encrypted
message for the first time, it gets automatical
This is an improvement on the series most recently sent in
id:20180110001228.2211-1-...@fifthhorseman.net (with the initial
version in id:20171212025225.11854-1-...@fifthhorseman.net).
The differences between this and v2 of this series are cleanup and
readability improvements suggested by David Br
This is technically an API change, but it is not an ABI change, and
it's merely a statement that limits what the library can do.
This is in parallel to notmuch_query_get_database(), which also takes
a const pointer.
---
lib/message.cc | 2 +-
lib/notmuch.h | 2 +-
2 files changed, 2 insertions(+
We've had _notmuch_message_database() internally for a while, and it's
useful. It turns out to be useful on the other side of the library
interface as well (i'll use it later in this series for "notmuch
show"), so we expose it publicly now.
---
lib/index.cc| 10 +-
lib/message
36 matches
Mail list logo
