notmuch show decrypt into mbox format

notmuch show decrypt into mbox format

[Sandra Snan]

This didn't decrypt:

    notmuch show --format=mbox --entire-thread=true --decrypt=true

The default text format to notmuch show does decrypt the parts just
fine. I wanted the mbox format so I could use it with b4 to extract
patches.

Re: notmuch show decrypt into mbox format

[David Bremner]

Sandra Snan <sandra.snan@idiomdrottning.org> writes:

> This didn't decrypt:
>
>     notmuch show --format=mbox --entire-thread=true --decrypt=true
>
> The default text format to notmuch show does decrypt the parts just
> fine. I wanted the mbox format so I could use it with b4 to extract
> patches.

Hmm. The code (format_part_mbox in notmuch-show.c) is pretty simple, it
basically reads the raw messages (up to gunzip and '^From ' escaping. I
guess we could add a second code path that parsed and decrypted the
messages before re-serializing them again. At the moment I don't have a
clear idea how much code that would be.

Re: notmuch show decrypt into mbox format

[Sandra Snan]

David Bremner <david@tethera.net> writes:
> I guess we could add a second code path that parsed and 
> decrypted the messages before re-serializing them again.

Or, as a stop gap measure, a warning when the flags are used 
together that mbox doesn't support decrypt.

I tried decrypting the pgp'd parts of the mbox export manually but 
it had =20 =2D characters that confused git am.

Finally saving the patches one by one with w in the Emacs interface to
notmuch gave me patches I could apply. (Just in case someone else
searches the mailing list for the same issue.)

Re: notmuch show decrypt into mbox format

[David Bremner]

Sandra Snan <sandra.snan@idiomdrottning.org> writes:

> David Bremner <david@tethera.net> writes:
>> I guess we could add a second code path that parsed and 
>> decrypted the messages before re-serializing them again.
>
> Or, as a stop gap measure, a warning when the flags are used 
> together that mbox doesn't support decrypt.

That seems do-able, thanks for the suggestion.

d

[PATCH] CLI/show: warn if crypto options are used with mbox format

[David Bremner]

This limitation seems somewhat hard to fix, but at least try to warn
users when combining crypto operations with mbox output format.

Because the default is --decrypt=auto, the warning is omitted if
--decrypt=auto is specified. While this is not great, it seems more
wrong to always warn, or to change the default because of this.
---
We could also make this a fatal error, I'm not sure which is better
 notmuch-show.c    |  7 +++++++
 test/T520-show.sh | 19 +++++++++++++++++++
 2 files changed, 26 insertions(+)

diff --git a/notmuch-show.c b/notmuch-show.c
index 7fb40ce9..97d0beb1 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -1399,6 +1399,13 @@ notmuch_show_command (notmuch_database_t *notmuch, int argc, char *argv[])
 	    fprintf (stderr, "Error: specifying parts is incompatible with mbox output format.\n");
 	    return EXIT_FAILURE;
 	}
+	if (params.crypto.decrypt != NOTMUCH_DECRYPT_FALSE
+	    && params.crypto.decrypt !=NOTMUCH_DECRYPT_AUTO) {
+	    fprintf (stderr, "Warning: mbox format does not support decryption (ignored)\n");
+	}
+	if (params.crypto.verify) {
+	    fprintf (stderr, "Warning: mbox format does not support signature verification (ignored)\n");
+	}
     } else if (format == NOTMUCH_FORMAT_RAW) {
 	/* raw format only supports single message display */
 	single_message = true;
diff --git a/test/T520-show.sh b/test/T520-show.sh
index 6bcf109c..65d2ece6 100755
--- a/test/T520-show.sh
+++ b/test/T520-show.sh
@@ -17,6 +17,25 @@ notmuch show foo..
 exit_code=$?
 test_expect_equal 1 $exit_code
 
+test_begin_subtest "warning for --mbox --decrypt"
+notmuch show --format=mbox --decrypt=true '*' 1>/dev/null 2>OUTPUT
+echo $? >> OUTPUT
+cat <<EOF > EXPECTED
+Warning: mbox format does not support decryption (ignored)
+Warning: mbox format does not support signature verification (ignored)
+0
+EOF
+test_expect_equal_file EXPECTED OUTPUT
+
+test_begin_subtest "warning for --mbox --verify"
+notmuch show --format=mbox --verify '*' 1>/dev/null 2>OUTPUT
+echo $? >> OUTPUT
+cat <<EOF > EXPECTED
+Warning: mbox format does not support signature verification (ignored)
+0
+EOF
+test_expect_equal_file EXPECTED OUTPUT
+
 test_begin_subtest "notmuch show --sort=newest-first"
 notmuch show --entire-thread=true '*' > EXPECTED
 notmuch show --entire-thread=true --sort=newest-first '*' > OUTPUT
-- 
2.43.0

Re: notmuch show decrypt into mbox format

[David Bremner]

Sandra Snan <sandra.snan@idiomdrottning.org> writes:

> Finally saving the patches one by one with w in the Emacs interface to
> notmuch gave me patches I could apply. (Just in case someone else
> searches the mailing list for the same issue.)

By the way, the mailscripts package (elpa-mailscripts on Debian)
contains some some add-on functions that might reduce the manual labour
in situations like this.

Re: notmuch show decrypt into mbox format

[Sandra Snan]

David Bremner <david@tethera.net> writes:
> By the way, the mailscripts package (elpa-mailscripts on Debian) 
> contains some some add-on functions that might reduce the manual 
> labour in situations like this. 

That's what I had been using, do they really work when the patches 
are encrypted?

I've been trying to go to b4 instead since I heard it was better at
guessing what commit the patches were made on if the sender forgot to
use the --base option when sending, and that uses mbox which for sure
does not work with encrypted patches.

Re: notmuch show decrypt into mbox format

[David Bremner]

Sandra Snan <sandra.snan@idiomdrottning.org> writes:

> David Bremner <david@tethera.net> writes:
>> By the way, the mailscripts package (elpa-mailscripts on Debian) 
>> contains some some add-on functions that might reduce the manual 
>> labour in situations like this. 
>
> That's what I had been using, do they really work when the patches 
> are encrypted?

probably not out of the box, but I guess it might be easier to hack
notmuch-extract-* on the emacs side than to extend 'notmuch show
--format=mbox'

Re: notmuch show decrypt into mbox format

[Sandra Snan]

David Bremner <david@tethera.net> writes:
> probably not out of the box, but I guess it might be easier to 
> hack notmuch-extract-* on the emacs side than to extend 'notmuch 
> show --format=mbox'

Those elpa-mailscripts also rely on calling notmuch show 
--format=mbox.

The elisp files (similar to what I had been using) shell out to 
the same Python scripts I was originally using (from the 
mailscripts package, but same source package on Debian) and the 
Python scripts in turn wrap notmuch show --format=mbox. So that's 
where I already was before starting the thread; scripts that don't 
work because --format=mbox doesn't decrypt the patches.


(Even though I am working on moving from them to b4 since someone told
me it supposedly does a slightly better job at guessing the base commit
when people send patches for old versions without formatting the patch
with --base so I was NIH making my own wrappers for notmuch show
--format=mbox similar to the ones in mailscripts.)

Re: [PATCH] CLI/show: warn if crypto options are used with mbox format

[David Bremner]

David Bremner <david@tethera.net> writes:

> This limitation seems somewhat hard to fix, but at least try to warn
> users when combining crypto operations with mbox output format.
>
> Because the default is --decrypt=auto, the warning is omitted if
> --decrypt=auto is specified. While this is not great, it seems more
> wrong to always warn, or to change the default because of this.

Applied to master, with some minor whitespace cleanup.

d