Re: [PATCH 07/20] cli/show: emit new whole-message crypto status output

2018-06-29 Thread David Bremner
Daniel Kahn Gillmor  writes:

>
> So we have bumped from 1 to 2 with just a simple addition in the past.
> But maybe that was from before we knew better?
>

probably.

> At any rate, since the only thing that we're doing is emitting
> message.crypto, i think we can avoid bumping the version in this series.
>

agreed.

> That said, i think i need to wrap the block with a test for
> (notmuch_format_version >= 4) in this case, right?

yeah, I think so, since otherwise there's no real specification for the
schmema of e.g. version 2 + random stuff.

>
> My new series will try out something like this, let me know what you
> think!
>

I approve this message.

d

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH 07/20] cli/show: emit new whole-message crypto status output

2018-06-29 Thread Daniel Kahn Gillmor
On Fri 2018-06-15 20:47:59 -0300, David Bremner wrote:
> Daniel Kahn Gillmor  writes:
>
>> +
>> +const _notmuch_message_crypto_t *msg_crypto = 
>> mime_node_get_message_crypto_status (node);
>> +if (msg_crypto->sig_list ||
>> +msg_crypto->decryption_status != NOTMUCH_MESSAGE_DECRYPTED_NONE) {
>> +sp->map_key (sp, "crypto");
>
> I believe the new stuff needs to guarded by
>
> if (notmuch_format_version >= 5)

hm, maybe it can all still be v4?  over in notmuch-client.h, it says:

/* The current structured output format version.  Requests for format
 * versions above this will return an error.  Backwards-incompatible
 * changes such as removing map fields, changing the meaning of map
 * fields, or changing the meanings of list elements should increase
 * this.  New (required) map fields can be added without increasing
 * this.
 */
#define NOTMUCH_FORMAT_CUR 4

i don't know exactly what "map fields" means here -- i don't think of
notmuch-show output as a "map" but maybe i'm using the terminology
wrong.

and, despite the comments above, the versioning actually looks like
this:

Version history
---

v1
- First versioned schema release.
- Added part.content-length and part.content-transfer-encoding fields.

v2
- Added the thread_summary.query field.

v3
- Replaced message.filename string with a list of filenames.
- Added part.content-disposition field.

v4
- replace signature error integer bitmask with a set of flags for
  individual errors.


So we have bumped from 1 to 2 with just a simple addition in the past.
But maybe that was from before we knew better?

At any rate, since the only thing that we're doing is emitting
message.crypto, i think we can avoid bumping the version in this series.

That said, i think i need to wrap the block with a test for
(notmuch_format_version >= 4) in this case, right?

My new series will try out something like this, let me know what you
think!

  --dkg


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH 07/20] cli/show: emit new whole-message crypto status output

2018-06-15 Thread David Bremner
Daniel Kahn Gillmor  writes:

> +
> + const _notmuch_message_crypto_t *msg_crypto = 
> mime_node_get_message_crypto_status (node);
> + if (msg_crypto->sig_list ||
> + msg_crypto->decryption_status != NOTMUCH_MESSAGE_DECRYPTED_NONE) {
> + sp->map_key (sp, "crypto");

I believe the new stuff needs to guarded by

if (notmuch_format_version >= 5)

d
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


[PATCH 07/20] cli/show: emit new whole-message crypto status output

2018-05-10 Thread Daniel Kahn Gillmor
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
is that the message have all of its encryption and signing protection
(the "cryptographic envelope") in a contiguous set of MIME layers at
the very outside of the message itself.

This is because messages with some subparts signed or encrypted, but
with other subparts with no cryptographic protection is very difficult
to reason about, and even harder for the user to make sense of or work
with.

For further characterization of the Cryptographic Envelope and some of
the usability tradeoffs, see here:

   
https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html#cryptographic-envelope
---
 devel/schemata  | 21 -
 notmuch-show.c  | 27 +++
 test/T350-crypto.sh | 19 +++
 test/T355-smime.sh  |  5 +++--
 4 files changed, 65 insertions(+), 7 deletions(-)

diff --git a/devel/schemata b/devel/schemata
index 42b1bcf3..6370eeac 100644
--- a/devel/schemata
+++ b/devel/schemata
@@ -14,7 +14,7 @@ are interleaved. Keys are printed as keywords (symbols 
preceded by a
 colon), e.g. (:id "123" :time 54321 :from "foobar"). Null is printed as
 nil, true as t and false as nil.
 
-This is version 4 of the structured output format.
+This is version 5 of the structured output format.
 
 Version history
 ---
@@ -34,6 +34,9 @@ v4
 - replace signature error integer bitmask with a set of flags for
   individual errors.
 
+v5
+- added message.crypto to identify overall message cryptographic state
+
 Common non-terminals
 
 
@@ -73,9 +76,25 @@ message = {
 tags:   [string*],
 
 headers:headers,
+crypto?:crypto,   # omitted if crypto disabled, or if no part was 
signed or encrypted.
 body?:  [part]# omitted if --body=false
 }
 
+# when showing the message, was any or all of it decrypted?
+msgdecstatus: "full"|"partial"
+
+# The overall cryptographic state of the message as a whole:
+crypto = {
+signed?:{
+  status:  sigstatus,
+  # was the set of signatures described under encrypted cover?
+  encrypted:   bool,
+},
+decrypted?: {
+  status: msgdecstatus,
+}
+}
+
 # A MIME part (format_part_sprinter)
 part = {
 id: int|string, # part id (currently DFS part number)
diff --git a/notmuch-show.c b/notmuch-show.c
index f0be8060..fea99bff 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -616,6 +616,33 @@ format_part_sprinter (const void *ctx, sprinter_t *sp, 
mime_node_t *node,
format_part_sprinter (ctx, sp, mime_node_child (node, 0), true, 
include_html);
sp->end (sp);
}
+
+   const _notmuch_message_crypto_t *msg_crypto = 
mime_node_get_message_crypto_status (node);
+   if (msg_crypto->sig_list ||
+   msg_crypto->decryption_status != NOTMUCH_MESSAGE_DECRYPTED_NONE) {
+   sp->map_key (sp, "crypto");
+   sp->begin_map (sp);
+   if (msg_crypto->sig_list) {
+   sp->map_key (sp, "signed");
+   sp->begin_map (sp);
+   sp->map_key (sp, "status");
+   format_part_sigstatus_sprinter (sp, msg_crypto->sig_list);
+   if (msg_crypto->signature_encrypted) {
+   sp->map_key (sp, "encrypted");
+   sp->boolean (sp, msg_crypto->signature_encrypted);
+   }
+   sp->end (sp);
+   }
+   if (msg_crypto->decryption_status != 
NOTMUCH_MESSAGE_DECRYPTED_NONE) {
+   sp->map_key (sp, "decrypted");
+   sp->begin_map (sp);
+   sp->map_key (sp, "status");
+   sp->string (sp, msg_crypto->decryption_status == 
NOTMUCH_MESSAGE_DECRYPTED_FULL ? "full" : "partial");
+   sp->end (sp);
+   }
+   sp->end (sp);
+   }
+
sp->end (sp);
return;
 }
diff --git a/test/T350-crypto.sh b/test/T350-crypto.sh
index b5067346..4c0f6f46 100755
--- a/test/T350-crypto.sh
+++ b/test/T350-crypto.sh
@@ -27,7 +27,7 @@ test_expect_equal "$output" "thread:XXX   2000-01-01 [1/1] 
Notmuch Test Suite; t
 test_begin_subtest "signature verification"
 output=$(notmuch show --format=json --verify subject:"test signed message 001" 
\
 | notmuch_json_show_sanitize \
-| sed -e 's|"created": [1234567890]*|"created": 946728000|')
+| sed -e 's|"created": [1234567890]*|"created": 946728000|g')
 expected='[[[{"id": "X",
  "match": true,
  "excluded": false,
@@ -35,6 +35,7 @@ expected='[[[{"id": "X",
  "timestamp": 946728000,
  "date_relative": "2000-01-01",
  "tags": ["inbox","signed"],
+ "crypto": {"signed": {"status": [{ "status