Re: [PATCH 07/20] cli/show: emit new whole-message crypto status output
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
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 17/20] cli/reply: add --protected-subject boolean flag
Daniel Kahn Gillmor writes:
> 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. This feels clumsier than i'd like, but we really don't
> want to be the ones who leak data on the wire that had been protected
> otherwise, and this seems like a safe way to ensure that the MUA is
> capable.
> ---
> doc/man1/notmuch-reply.rst | 12
> notmuch-client.h | 4 +++-
> notmuch-reply.c| 20
> notmuch-show.c | 9 -
> test/T356-protected-headers.sh | 7 +++
> 5 files changed, 42 insertions(+), 10 deletions(-)
>
> diff --git a/doc/man1/notmuch-reply.rst b/doc/man1/notmuch-reply.rst
> index c893ba04..08aadba6 100644
> --- a/doc/man1/notmuch-reply.rst
> +++ b/doc/man1/notmuch-reply.rst
> @@ -70,6 +70,18 @@ Supported options for **reply** include
> order, and copy values from the first that contains something
> other than only the user's addresses.
>
> +``--protected-subject=(true|false)``
> +
> +Indicates that the replying client plans to protect (hide) the
> +subject in the subsequent reply. When replying to an encrypted
> +message that itself has an encrypted subject, **notmuch**
> +**reply** needs to propose a subject for the new reply e-mail. If
> +the client can handle protected subjects safely (if this flag is
> +set to ``true``), then the cleartext subject will be proposed.
> +Otherwise, the external (dummy) subject is proposed, to avoid
> +leaking the previously protected subject on reply. Defaults to
> +``false``.
> +
> ``--decrypt=(false|auto|true)``
What about using a keyword argument like --protected=subject ? that
would allow easy future addition of protected headers by specifying e.g.
--protected=subject --protected=references
> If ``true``, decrypt any MIME encrypted parts found in the
> diff --git a/notmuch-client.h b/notmuch-client.h
> index 0af96986..014fa064 100644
> --- a/notmuch-client.h
> +++ b/notmuch-client.h
> @@ -235,7 +235,9 @@ typedef enum {
> /* typical "notmuch show" or other standard output: */
> HEADERS_FORMAT_NORMAL = 0,
> /* set only if this is being generated as a reply: */
> -HEADERS_FORMAT_REPLY = 1 << 0
> +HEADERS_FORMAT_REPLY = 1 << 0,
> +/* set only if the invoking MUA will responsibly protect the subject
> line */
> +HEADERS_FORMAT_PROTECTED_SUBJECT = 1 << 1
> } notmuch_headers_format_flags;
a minor improvement might be to end the list with a ',' from the start
to minimize diff.
>
> diff --git a/notmuch-reply.c b/notmuch-reply.c
> index 749eac6d..d1092ce9 100644
> --- a/notmuch-reply.c
> +++ b/notmuch-reply.c
> @@ -612,7 +612,8 @@ static int do_reply(notmuch_config_t *config,
> notmuch_query_t *query,
> notmuch_show_params_t *params,
> int format,
> - bool reply_all)
> + bool reply_all,
> + bool protected_subject)
similarly, maybe use the already defined flag enum rather than a boolean
here.
d
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 14/20] test: show cryptographic envelope information for signed mails
Daniel Kahn Gillmor writes:
> +test_begin_subtest "show cryptographic envelope on signed mail"
> +output=$(notmuch show --verify --format=json
> id:simple-signed-m...@crypto.notmuchmail.org)
> +test_json_nodes <<<"$output" \
> +'crypto:[0][0][0]["crypto"]={"signed": {"status":
> [{"created": 1525609971, "fingerprint":
> "5AEAB11F5E33DCE875DDB75B6D92612D94E46381", "status": "good"}]}}'
> +
> +test_begin_subtest "verify signed protected header"
> +output=$(notmuch show --verify --format=json
> id:signed-protected-hea...@crypto.notmuchmail.org)
> +test_json_nodes <<<"$output" \
> +'crypto:[0][0][0]["crypto"]={"signed": {"status":
> [{"created": 1525350527, "fingerprint":
> "5AEAB11F5E33DCE875DDB75B6D92612D94E46381", "status": "good"}], "headers":
> ["Subject"]}}'
> +
If possible, it would be good to avoid hardcoding the fingerprint, to
minimize the number of places we have to change when e.g. gpg starts
reject our 1K test key.
d
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
