notmuch/notmuch-show.c, branch 0.29.1

cli/show: add information about which headers were protected

2019-05-29T11:11:50Z

The header-mask member of the per-message crypto object allows a clever UI frontend to mark whether a header was protected (or not). And if it was protected, it contains enough information to show useful detail to an interested user. For example, an MUA could offer a "show what this message's Subject looked like on the wire" feature in expert mode. As before, we only handle Subject for now, but we might be able to handle other headers in the future. Signed-off-by: Daniel Kahn Gillmor Amended by db: tweaked schemata notation.

cli/show: emit payload subject instead of outside subject

2019-05-29T11:05:01Z

Correctly fix the two outstanding tests so that the protected (hidden) subject is properly reported. Signed-off-by: Daniel Kahn Gillmor

cli/show: emit headers after emitting body

2019-05-29T11:02:32Z

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. Signed-off-by: Daniel Kahn Gillmor

cli/show: emit new whole-message crypto status output

2019-05-26T11:20:23Z

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

cli/notmuch-show: support gzipped files

2019-05-03T10:48:43Z

This drops "file" from mime_node_context and just uses a local variable. It also uses the new gzip aware utility routines recently added to util/gmime-extra.c. The use of gzopen / gzfile in addition is a bit icky, but the choice is between that, and providing yet another readline implimentation that understands GMime streams.

gmime-cleanup: pass NULL arguments explicitly where GMime 3.0 expects it

2019-05-03T09:57:27Z

Several GMime 2.6 functions sprouted a change in the argument order in GMime 3.0. We had a compatibility layer here to be able to handle compiling against both GMime 2.6 and 3.0. Now that we're using 3.0 only, rip out the compatibility layer for those functions with changed argument lists, and explicitly use the 3.0 argument lists. Signed-off-by: Daniel Kahn Gillmor

gmime-cleanup: use GMime 3.0 function names

2019-05-03T09:57:16Z

Signed-off-by: Daniel Kahn Gillmor

gmime-cleanup: use GMime 3.0 data types

2019-05-03T09:57:06Z

Signed-off-by: Daniel Kahn Gillmor

gmime-cleanup: always support session keys

2019-05-03T09:55:32Z

Our minimum version of GMime 3.0 always supports good session key handling. signed-off-by: Daniel Kahn Gillmor

gmime-cleanup: remove obsolete gpg_path configuration option and crypto contexts

2019-05-03T09:55:04Z

Note that we do keep ignoring the gpg_path configuration option, though, to avoid breakage of existing installations. It is ignored like any other unknown configuration option, but we at least document that it is ignored so that people who find it in their legacy configs can know that it's safe to drop. signed-off-by: Daniel Kahn Gillmor