notmuch/test/T350-crypto.sh, branch 0.26_rc0thread-based email index, search, and tagginghttps://git.notmuchmail.org/git/notmuch/atom?h=0.26_rc02017-10-20T22:52:49Ztest: use $(dirname "$0") for sourcing test-lib.sh2017-10-20T22:52:49ZJani Nikulajani@nikula.org2017-09-25T20:38:19Zurn:sha1:a863de1e43ee34f6f5794a2759fdceb287e851aa
Don't assume the tests are always run from within the source tree.
tests: prepare for more crypto tests (using add_gnupg_home)2017-10-14T13:53:42ZDaniel Kahn Gillmordkg@fifthhorseman.net2017-10-10T05:49:08Zurn:sha1:ee5df7d7db895a427aa1e4343b2c8f794a0b2d73
Move add_gnupg_home to test-lib.sh to prepare it for reuse.
lib: index the content-type of the parts of encrypted messages2017-09-17T23:01:19ZDaniel Kahn Gillmordkg@fifthhorseman.net2017-09-16T14:59:05Zurn:sha1:f4ac5ecd5c6db78982a0730059061cbe946ca079
This is a logical followup to "lib: index the content type of
signature parts", which will make it easier to record the message
structure of all messages.
lib: index the content type of signature parts2017-09-17T23:01:00ZJani Nikulajani@nikula.org2017-09-16T14:59:04Zurn:sha1:55c047ee0b0c9081ead76925ee1adaeb858264dd
It's useful (*) to be able to easily find messages with certain types
of signatures. Having the mimetype: prefix searches fail for some
content types is also genuinely surprising (*). Index the content type
of signature parts.
While at it, switch to the gmime convenience constants for content and
signature part indexes.
*) At least for developers of email software!
test: signed and encrypted part content type indexing2017-09-17T23:00:43ZJani Nikulajani@nikula.org2017-09-16T14:59:03Zurn:sha1:30c276146596769177e1e3c200d8bb94d4cf8531
Add known broken subtests for searching signed and encrypted messages
using mimetype: prefix search for the content-types of signed and
encrypted parts.
test/crypto: remove headers more robustly2017-09-03T11:06:15ZDavid Bremnerdavid@tethera.net2017-09-01T23:59:47Zurn:sha1:ec37900c5f0316e1f7345fe413402e6dc8bb9547
In [1], Vladimir Panteleev observed that the In-Reply-To and
References headers could be wrapped in the 'default' output format of
notmuch-reply, depending on the version of Emacs creating the
message. In my own experiments notmuch-reply sometimes wraps headers
with only one message-id if that message-id is long enough. However it
happens, this causes the previous approach using grep to fail.
Since I found the proposed unwrapping shell fragment in [1] a bit hard
to follow, I decided to write a little python script instead. Then
Tomi suggested a slight generalization of my script, and here we are.
[1] id:20170817175145.3204-7-notmuch@thecybershadow.net
test/crypto: mark extra space in userid as a bug in gmime-2.62017-07-14T20:58:09ZDavid Bremnerdavid@tethera.net2017-06-03T00:29:25Zurn:sha1:a58c75fdf6120aa3861e95a4a61fa268dee6a690
I can't see the space in the output of gpg -K --with-colons
test/crypto: add test for corrupted signatures2017-07-05T10:36:20ZDavid Bremnerdavid@tethera.net2017-06-03T17:47:40Zurn:sha1:87ca29b7a737a9b52f1916156aef9511939b4376
Have an empty list of signatures is not the nicest mechanism to signal
complete failure to verify, but it's the one we currently have.
test: add test for modified pgp/mime signed message2017-07-05T10:36:20ZDavid Bremnerdavid@tethera.net2017-06-03T17:47:39Zurn:sha1:4f48ae4a5fcc842b1c010ba11aff902cd67ddc6f
This is a good thing to test in any case, but particularly as we hit
the dark corners of the gmime crypto API.
cli: implement structured output version 42017-07-04T11:32:44ZDavid Bremnerdavid@tethera.net2017-06-03T17:47:34Zurn:sha1:e1b7d32db00ea8afaa1f2ae31bdaa5cb423dda96
Since the error field is unused by the emacs front end, no changes are
needed other than bumping the format version number.
As it is, this is a bit overengineered, but it will reduce duplication
when we support gmime 3.0