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
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 fo
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 stru
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 92e5bd1b..a67b43
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
INFO
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 s
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
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:
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.
Signe
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 (n
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, bu
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
id:smime-one
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 inserti
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
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 1
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 o
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
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
https://notmuchmail.or
18 matches
Mail list logo
