Re: test suite: FIXED messages are misordered with tests

2020-05-12 Thread David Bremner
Daniel Kahn Gillmor writes: > > Clearly, that FIXED should come *after* the "T356-protected-headers:" > separator. > Can you reproduce this without running the tests in parallel? d ___ notmuch mailing list notmuch@notmuchmail.org

[PATCH v2 3/9] cli: include wrapped part of PKCS#7 SignedData in the MIME tree

2020-05-12 Thread Daniel Kahn Gillmor
Unwrap a PKCS#7 SignedData part unconditionally when the cli is traversing the MIME tree, and return it as a "child" of what would otherwise be a leaf in the tree. Unfortunately, this also breaks the JSON output. We will fix that next. Signed-off-by: Daniel Kahn Gillmor --- mime-node.c

Handle PKCS#7 S/MIME messages v2

2020-05-12 Thread Daniel Kahn Gillmor
This revision of the PKCS#7 S/MIME handling series is based on (and very similar to) the series sent on the thread starting at id:20200430201328.725651-1-...@fifthhorseman.net However, it is rebased after more gracefully handling the subtle errors in X.509 certificate validity when built against

[PATCH v2 1/9] lib: index PKCS7 SignedData parts

2020-05-12 Thread Daniel Kahn Gillmor
When we are indexing, we should treat SignedData parts the same way that we treat a multipart object, indexing the wrapped part as a distinct MIME object. Unfortunately, this means doing some sort of cryptographic verification whose results we throw away, because GMime doesn't offer us any way to

[PATCH v2 2/9] smime: Identify encrypted S/MIME parts during indexing

2020-05-12 Thread Daniel Kahn Gillmor
We don't handle them correctly yet, but we can at least mark them as being encrypted. Signed-off-by: Daniel Kahn Gillmor --- lib/index.cc | 4 test/T355-smime.sh | 1 - 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/lib/index.cc b/lib/index.cc index bbf13dc5..f029b334

[PATCH v2 4/9] cli/show: If a leaf part has children, show them instead of omitting

2020-05-12 Thread Daniel Kahn Gillmor
Until we did PKCS#7 unwrapping, no leaf MIME part could have a child. Now, we treat the unwrapped MIME part as the child of the PKCS#7 SignedData object. So in that case, we want to show it instead of deliberately omitting the content. This fixes the test of the protected subject in

[PATCH v2 5/9] cli/reply: Ignore PKCS#7 wrapper parts when replying

2020-05-12 Thread Daniel Kahn Gillmor
When composing a reply, no one wants to see this line in the proposed message: Non-text part: application/pkcs7-mime So we hide it, the same way we hide PGP/MIME cruft. Signed-off-by: Daniel Kahn Gillmor --- notmuch-reply.c| 5 +++-- test/T355-smime.sh | 1 - 2 files changed, 3

[PATCH v2 7/9] crypto: handle PKCS#7 envelopedData in _notmuch_crypto_decrypt

2020-05-12 Thread Daniel Kahn Gillmor
In the two places where _notmuch_crypto_decrypt handles multipart/encrypted messages (PGP/MIME), we should also handle PKCS#7 envelopedData (S/MIME). This is insufficient for fully handling S/MIME encrypted data because _notmuch_crypto_decrypt isn't yet actually invoked for envelopedData parts,

[PATCH v2 6/9] crypto: Make _notmuch_crypto_decrypt take a GMimeObject

2020-05-12 Thread Daniel Kahn Gillmor
As we prepare to handle S/MIME-encrypted PKCS#7 EnvelopedData (which is not multipart), we don't want to be limited to passing only GMimeMultipartEncrypted MIME parts to _notmuch_crypto_decrypt. There is no functional change here, just a matter of adjusting how we pass arguments internally.

[PATCH v2 9/9] smime: Index cleartext of envelopedData when requested

2020-05-12 Thread Daniel Kahn Gillmor
Signed-off-by: Daniel Kahn Gillmor --- lib/index.cc | 5 +++-- test/T355-smime.sh | 2 -- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/lib/index.cc b/lib/index.cc index da9a3abe..826aa341 100644 --- a/lib/index.cc +++ b/lib/index.cc @@ -656,8 +656,9 @@ _index_pkcs7_part

[PATCH v2 8/9] smime: Pass PKCS#7 envelopedData to node_decrypt_and_verify

2020-05-12 Thread Daniel Kahn Gillmor
This change means we can support "notmuch show --decrypt=true" for S/MIME encrypted messages, resolving several outstanding broken tests, including all the remaining S/MIME protected header examples. We do not yet handle indexing the cleartext of S/MIME encrypted messages, though. Signed-off-by:

[PATCH 2/2 v2] smime: tests of X.509 certificate validity are known-broken on GMime < 3.2.7

2020-05-12 Thread Daniel Kahn Gillmor
When checking cryptographic signatures, Notmuch relies on GMime to tell it whether the certificate that signs a message has a valid User ID or not. If the User ID is not valid, then notmuch does not report the signer's User ID to the user. This means that the consumer of notmuch's cryptographic

Re: [PATCH 1/2 v2] test-lib: mark function variables as local

2020-05-12 Thread Daniel Kahn Gillmor
On Sat 2020-05-09 08:47:10 -0300, David Bremner wrote: > I'm confused about where to apply 2/2. If I apply it on top of (updated) > master, it causes test failures. If I apply after the rest of the > patches in this thread then presumably there is some interval where the > build is broken (if only

test suite: FIXED messages are misordered with tests

2020-05-12 Thread Daniel Kahn Gillmor
I'm debugging/diagnosing/trying to clean up some "FIXED" known-broken tests right now. Sometimes, depending on circumstances i can't predict (race conditions?), I see funny output like: ~~~ Use "make V=1" to see the details for passing and known broken tests. INFO: using 2m timeout for tests

[PATCH] configure: report GMime minimum version in ./configure output

2020-05-12 Thread Daniel Kahn Gillmor
We already report the minimum version for Glib, zlib, and Xapian development libraries. For consistency, report it for GMime as well. Signed-off-by: Daniel Kahn Gillmor --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index

Re: feature request: parameters for reply templates

2020-05-12 Thread Tomi Ollila
On Tue, May 12 2020, Jörg Volbers wrote: >> My gut reaction is that doing more formatting in notmuch reply >> is probably a mistake; it's hard enough to get two users to >> agree on these kind of customizations, never mind two different >> MUAs. Probably what we need to do is make sure the

Re: feature request: parameters for reply templates

2020-05-12 Thread Jörg Volbers
My gut reaction is that doing more formatting in notmuch reply is probably a mistake; it's hard enough to get two users to agree on these kind of customizations, never mind two different MUAs. Probably what we need to do is make sure the structured (json/s-expr) output has enough information

Re: feature request: parameters for reply templates

2020-05-12 Thread David Bremner
Emmanuel Beffara writes: > > I use `notmuch reply` with the default format indirectly, because I use > bower an it delegates the task of preparing replies to this command. I > feel it would make sense to define new settings to handle all this, but > maybe there are good reasons not to? > My gut