[PATCH 17/20] cli/reply: add --protected-subject boolean flag

[David Bremner]

Daniel Kahn Gillmor <dkg at fifthhorseman.net> 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