notmuch/test/T350-crypto.sh, branch 0.34

cli/show: produce "email" element in sigstatus

2021-06-26T16:07:47Z

When the certificate that signs a message is known to be valid, GMime is capable of reporting on the e-mail address embedded in the certificate. We pass this information along to the caller of "notmuch show", as often only the e-mail address of the certificate has actually been checked/verified. Furthermore, signature verification should probably at some point compare the e-mail address of the caller against the sender address of the message itself. Having to parse what gmime thinks is a "userid" to extract an e-mail address seems clunky and unnecessary if gmime already thinks it knows what the e-mail address is. See id:878s41ax6t.fsf@fifthhorseman.net for more motivation and discussion. Signed-off-by: Daniel Kahn Gillmor

test: source $NOTMUCH_SRCDIR/test/test-lib-emacs.sh

2021-06-03T12:29:27Z

Sourcing test-lib.sh will cd to TMP_DIRECTORY, so relative path in $0 will not work in previous version . $(dirname "$0")/test-lib-emacs.sh Now individual test scripts -- e.g. ./test/T310-emacs.sh will work.

test: split emacs functionality to its own file

2021-05-17T10:29:04Z

This way it's easier to identify the tests that do require emacs stuff. Signed-off-by: Felipe Contreras

test: add external prereqs to many emacs tests

2021-05-02T00:15:27Z

The tests fail otherwise. Signed-off-by: Felipe Contreras

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

test/crypto: add_gnupg_home should have ultimate trust on "its own" key

2019-05-07T09:42:21Z

The typical use case for gpg is that if you control a secret key, you mark it with "ultimate" ownertrust. The opaque --import-ownertrust mechanism is GnuPG's standard mechanism to set up ultimate ownertrust (the ":6:" means "ultimate", for whatever reason). We adjust the test suite to match this change, inverting the sense of one test: since the default is now that the user ID of the suite's own key is valid, we change the test to make sure that the user ID is not emitted when it is *not* valid. Signed-off-by: Daniel Kahn Gillmor

test: simplify user ID handling

2019-05-07T09:42:11Z

The user ID on the self-test is a little bit clunky-looking. It also may end up showing up elsewhere in the test suite. Centralizing the user ID in one place should make it easier to handle if it ever changes, and should make tests easier to read. Signed-off-by: Daniel Kahn Gillmor

test/crypto: clarify the difference between ownertrust and validity

2019-05-07T09:42:01Z

This is a subtle difference, but the output of notmuch shouldn't ever change based on ownertrust itself -- notmuch is intended to show valid User IDs, and to avoid showing invalid User IDs. It so happens that setting ownertrust of a key to ultimate sets all associated user IDs to "full" validity, so the test is correct, but just misnamed. Signed-off-by: Daniel Kahn Gillmor

gmime-cleanup: tests should only care about gmime 3

2019-05-03T09:55:44Z

note that "notmuch-show for message with invalid From" is still broken in T310-emacs.sh. It would be good to debug what's going on there and try to get it fixed! signed-off-by: Daniel Kahn Gillmor

crypto: Avoid pretending to verify signatures on unsigned encrypted mail

2019-04-26T11:03:15Z

Unsigned encrypted mail shows up with a weird empty signature list. If we successfully decrypted and there was no signature in it, we should just not show a sigstatus at all. The documentation for g_mime_decrypt_result_get_signatures says: a GMimeSignatureList or NULL if the stream was not signed.