Re: [PATCH 3/6] Move to dh 12
On Tue 2019-12-03 19:17:19 -0400, David Bremner wrote: > I've merged all except this patch, Thanks! > and the wrap-and-sort. No real objection to the latter, but it is too > painful to rebase, and will need regeneration. I've regenerated it and sent it to the list. the earlier you apply wrap-and-sort -ast, the nicer it is for future diffs :) I'll take a look at the dh12 migration and dh_missing soon. -dkg signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 4/6 v2] wrap-and-sort -ast
Signed-off-by: Daniel Kahn Gillmor
---
debian/control | 105
debian/notmuch-mutt.install | 2 +-
debian/notmuch-vim.dirs | 4 +-
debian/notmuch-vim.install | 4 +-
debian/notmuch.install | 2 +-
debian/notmuch.manpages | 18 +++
6 files changed, 85 insertions(+), 50 deletions(-)
diff --git a/debian/control b/debian/control
index 9e5533d1..1c9427b2 100644
--- a/debian/control
+++ b/debian/control
@@ -4,35 +4,37 @@ Priority: optional
Maintainer: Carl Worth
Uploaders:
Jameson Graef Rollins ,
- David Bremner
-Build-Conflicts: ruby1.8, gdb-minimal, gdb [ia64 mips mips64el]
+ David Bremner ,
+Build-Conflicts:
+ gdb [ia64 mips mips64el],
+ gdb-minimal,
+ ruby1.8,
Build-Depends:
- dpkg-dev (>= 1.17.14),
+ bash-completion (>=1.9.0~),
debhelper (>= 11~),
- pkg-config,
- libxapian-dev,
+ dh-elpa (>= 1.3),
+ dh-python,
+ dpkg-dev (>= 1.17.14),
+ dtach (>= 0.8) ,
+ emacs-nox | emacs-gtk | emacs-lucid | emacs25-nox | emacs25 (>=25~) |
emacs25-lucid (>=25~) | emacs24-nox | emacs24 (>=24~) | emacs24-lucid (>=24~),
+ gdb [!ia64 !mips !mips64el !kfreebsd-any !alpha] ,
+ gnupg ,
+ gpgsm ,
libgmime-3.0-dev (>= 3.0.3~),
+ libpython3-all-dev,
libtalloc-dev,
+ libxapian-dev,
libz-dev,
+ pkg-config,
python3-all (>= 3.1.2-7~),
- dh-python,
- dh-elpa (>= 1.3),
python3-cffi,
python3-pytest,
python3-pytest-cov,
python3-setuptools,
python3-sphinx,
- libpython3-all-dev,
- ruby, ruby-dev (>>1:1.9.3~),
- emacs-nox | emacs-gtk | emacs-lucid |
- emacs25-nox | emacs25 (>=25~) | emacs25-lucid (>=25~) |
- emacs24-nox | emacs24 (>=24~) | emacs24-lucid (>=24~),
- gdb [!ia64 !mips !mips64el !kfreebsd-any !alpha] ,
- dtach (>= 0.8) ,
- gpgsm ,
- gnupg ,
- bash-completion (>=1.9.0~),
- texinfo
+ ruby,
+ ruby-dev (>>1:1.9.3~),
+ texinfo,
Standards-Version: 4.4.1
Homepage: https://notmuchmail.org/
Vcs-Git: https://git.notmuchmail.org/git/notmuch -b release
@@ -41,8 +43,14 @@ Rules-Requires-Root: no
Package: notmuch
Architecture: any
-Depends: libnotmuch5 (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}
-Recommends: elpa-notmuch | notmuch-vim | notmuch-mutt | alot, gnupg-agent,
gpgsm
+Depends:
+ libnotmuch5 (= ${binary:Version}),
+ ${misc:Depends},
+ ${shlibs:Depends},
+Recommends:
+ elpa-notmuch | notmuch-vim | notmuch-mutt | alot,
+ gnupg-agent,
+ gpgsm,
Description: thread-based email index, search and tagging
Notmuch is a system for indexing, searching, reading, and tagging
large collections of email messages in maildir or mh format. It uses
@@ -54,8 +62,11 @@ Description: thread-based email index, search and tagging
Package: libnotmuch5
Section: libs
Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
-Pre-Depends: ${misc:Pre-Depends}
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends},
+Pre-Depends:
+ ${misc:Pre-Depends},
Description: thread-based email index, search and tagging (runtime)
Notmuch is a system for indexing, searching, reading, and tagging
large collections of email messages in maildir or mh format. It uses
@@ -68,7 +79,9 @@ Description: thread-based email index, search and tagging
(runtime)
Package: libnotmuch-dev
Section: libdevel
Architecture: any
-Depends: ${misc:Depends}, libnotmuch5 (= ${binary:Version})
+Depends:
+ libnotmuch5 (= ${binary:Version}),
+ ${misc:Depends},
Description: thread-based email index, search and tagging (development)
Notmuch is a system for indexing, searching, reading, and tagging
large collections of email messages in maildir or mh format. It uses
@@ -81,7 +94,10 @@ Description: thread-based email index, search and tagging
(development)
Package: python3-notmuch
Architecture: all
Section: python
-Depends: ${misc:Depends}, ${python3:Depends}, libnotmuch5 (>=
${source:Version})
+Depends:
+ libnotmuch5 (>= ${source:Version}),
+ ${misc:Depends},
+ ${python3:Depends},
Description: Python 3 interface to the notmuch mail search and index library
Notmuch is a system for indexing, searching, reading, and tagging
large collections of email messages in maildir or mh format. It uses
@@ -94,7 +110,9 @@ Description: Python 3 interface to the notmuch mail search
and index library
Package: ruby-notmuch
Architecture: any
Section: ruby
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends},
Description: Ruby interface to the notmuch mail search and index library
Notmuch is a system for indexing, searching, reading, and tagging
large collections of email messages in maildir or mh format. It uses
@@ -107,13 +125,17 @@ Description: Ruby interface to the notmuch mail search
and index library
Package: notmuch-emacs
Section: oldlibs
Architecture: all
-Depends: elpa-notmuch, ${misc:Depends}
+Depends:
+ elpa-notmuch,
+ ${misc:Depends},
Description: thread-based email index, search and tagging (transitional
package)
This dummy package help ease transition to the new package elpa-notmuch
Package:
[PATCH 09/14] mime-node: Clean up unwrapped MIME parts correctly.
Avoid a memory leak in the notmuch command line.
gmime_multipart_encrypted_decrypt returns a GMimeObject marked by
GMime as "transfer full", so we are supposed to clean up after it.
When parsing a message, notmuch would leak one GMimeObject part per
multipart/encrypted MIME layer. We clean it up by analogy with
cleaning up the signature list associated with a MIME node.
Signed-off-by: Daniel Kahn Gillmor
---
mime-node.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/mime-node.c b/mime-node.c
index 2a823dfd..ff6805bf 100644
--- a/mime-node.c
+++ b/mime-node.c
@@ -192,6 +192,26 @@ set_signature_list_destructor (mime_node_t *node)
}
}
+/* Unwrapped MIME part destructor */
+static int
+_unwrapped_child_free (GMimeObject **proxy)
+{
+g_object_unref (*proxy);
+return 0;
+}
+
+/* Set up unwrapped MIME part destructor */
+static void
+set_unwrapped_child_destructor (mime_node_t *node)
+{
+GMimeObject **proxy = talloc (node, GMimeObject *);
+
+if (proxy) {
+ *proxy = node->unwrapped_child;
+ talloc_set_destructor (proxy, _unwrapped_child_free);
+}
+}
+
/* Verify a signed mime node */
static void
node_verify (mime_node_t *node, GMimeObject *part)
@@ -238,6 +258,8 @@ node_decrypt_and_verify (mime_node_t *node, GMimeObject
*part)
node->ctx->crypto->decrypt,
message,
encrypteddata,
_result, );
+ if (node->unwrapped_child)
+ set_unwrapped_child_destructor (node);
}
if (! node->unwrapped_child) {
fprintf (stderr, "Failed to decrypt part: %s\n",
--
2.24.0
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 06/14] tests/smime: add tests for S/MIME SignedData
Add a simple S/MIME SignedData message, taken from an upcoming draft
of
https://datatracker.ietf.org/doc/draft-autocrypt-lamps-protected-headers/
RFC 8551 describes a SignedData, a one-part clearsigned object that is
more resistant to common patterns of MTA message munging than
multipart/signed (but has the downside that it is only readable by
clients that implement S/MIME).
To make sure sure notmuch can handle this kind of object, we want to
know a few things:
Already working:
- Is the content of the SignedData object indexed? It actually is
right now because of dumb luck -- i think we're indexing the raw
CMS object and it happens to contain the cleartext of the message
in a way that we can consume it before passing it on to Xapian.
- Are we accidentally indexing the embedded PKCS#7 certificates? We
don't want to, and for some reason I don't understand, our indexing
is actually skipping the embedded certificates already. That's
good!
Still need fixing:
- do we know the MIME type of the embedded part?
- do we know that the message is signed?
- can notmuch-show read its content?
- can notmuch-show indicate the signature validity?
- can notmuch-reply properly quote and attribute content?
Signed-off-by: Daniel Kahn Gillmor
---
test/T355-smime.sh | 76 +
test/corpora/pkcs7/smime-onepart-signed.eml | 51 ++
2 files changed, 127 insertions(+)
create mode 100644 test/corpora/pkcs7/smime-onepart-signed.eml
diff --git a/test/T355-smime.sh b/test/T355-smime.sh
index cbd3e5a6..9055e589 100755
--- a/test/T355-smime.sh
+++ b/test/T355-smime.sh
@@ -96,4 +96,80 @@ Verification successful
EOF
test_expect_equal_file EXPECTED OUTPUT
+add_email_corpus pkcs7
+
+test_begin_subtest "index PKCS#7 SignedData message"
+output=$(notmuch search --output=messages Thanks)
+expected=id:smime-onepart-signed@protected-headers.example
+test_expect_equal "$expected" "$output"
+
+test_begin_subtest "do not index embedded certificates from PKCS#7 SignedData"
+output=$(notmuch search --output=messages 'LAMPS Certificate')
+expected=''
+test_expect_equal "$expected" "$output"
+
+test_begin_subtest "know the MIME type of the embedded part in PKCS#7
SignedData"
+test_subtest_known_broken
+output=$(notmuch search --output=messages 'mimetype:text/plain')
+expected=id:smime-onepart-signed@protected-headers.example
+test_expect_equal "$expected" "$output"
+
+test_begin_subtest "PKCS#7 SignedData message is tagged 'signed'"
+test_subtest_known_broken
+output=$(notmuch dump id:smime-onepart-signed@protected-headers.example)
+expected='#notmuch-dump batch-tag:3 config,properties,tags
++inbox +signed +unread -- id:smime-onepart-signed@protected-headers.example'
+test_expect_equal "$expected" "$output"
+
+test_begin_subtest "show contents of PKCS#7 SignedData message"
+test_subtest_known_broken
+output=$(notmuch show --format=raw --part=2
id:smime-onepart-signed@protected-headers.example)
+whitespace=' '
+expected="Bob, we need to cancel this contract.
+
+Please start the necessary processes to make that happen today.
+
+Thanks, Alice
+--${whitespace}
+Alice Lovelace
+President
+OpenPGP Example Corp"
+test_expect_equal "$expected" "$output"
+
+test_begin_subtest "reply to PKCS#7 SignedData message with proper quoting and
attribution"
+test_subtest_known_broken
+output=$(notmuch reply id:smime-onepart-signed@protected-headers.example)
+expected="From: Notmuch Test Suite
+Subject: Re: The FooCorp contract
+To: Alice Lovelace , Bob Babbage
+In-Reply-To:
+References:
+
+On Tue, 26 Nov 2019 20:11:29 -0400, Alice Lovelace wrote:
+> Bob, we need to cancel this contract.
+>${whitespace}
+> Please start the necessary processes to make that happen today.
+>${whitespace}
+> Thanks, Alice
+> --${whitespace}
+> Alice Lovelace
+> President
+> OpenPGP Example Corp"
+test_expect_equal "$expected" "$output"
+
+test_begin_subtest "show PKCS#7 SignedData outputs valid JSON"
+output=$(notmuch show --format=json
id:smime-onepart-signed@protected-headers.example)
+test_valid_json "$output"
+
+test_begin_subtest "Verify signature on PKCS#7 SignedData message"
+test_subtest_known_broken
+output=$(notmuch show --format=json
id:smime-onepart-signed@protected-headers.example)
+test_json_nodes <<<"$output" \
+'crypto:[0][0][0]["crypto"]["signed"]["status"][0]={
+"created" : 1574813489,
+"expires" : 2611032858,
+"fingerprint" :
"702BA4B157F1E2B7D16B0C6A5FFC8A7DE2057DEB",
+"status" : "good"
+ }'
+
test_done
diff --git a/test/corpora/pkcs7/smime-onepart-signed.eml
b/test/corpora/pkcs7/smime-onepart-signed.eml
new file mode 100644
index ..070303b7
--- /dev/null
+++ b/test/corpora/pkcs7/smime-onepart-signed.eml
@@ -0,0 +1,51 @@
+Received: from localhost (localhost [127.0.0.1]); Tue, 26 Nov 2019
+ 20:11:46 -0400 (UTC-04:00)
[PATCH 12/14] cli/reply: Ignore PKCS#7 wrapper parts when replying
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 insertions(+), 3 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 2c30f6f9..ceb4f39b 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -65,8 +65,9 @@ format_part_reply (GMimeStream *stream, mime_node_t *node)
GMimeContentDisposition *disposition =
g_mime_object_get_content_disposition (node->part);
if (g_mime_content_type_is_type (content_type, "application",
"pgp-encrypted") ||
- g_mime_content_type_is_type (content_type, "application",
"pgp-signature")) {
- /* Ignore PGP/MIME cruft parts */
+ g_mime_content_type_is_type (content_type, "application",
"pgp-signature") ||
+ g_mime_content_type_is_type (content_type, "application",
"pkcs7-mime")) {
+ /* Ignore PGP/MIME and S/MIME cruft parts */
} else if (g_mime_content_type_is_type (content_type, "text", "*") &&
! g_mime_content_type_is_type (content_type, "text",
"html")) {
show_text_part_content (node->part, stream,
NOTMUCH_SHOW_TEXT_PART_REPLY);
diff --git a/test/T355-smime.sh b/test/T355-smime.sh
index 399bd91c..ddc91a56 100755
--- a/test/T355-smime.sh
+++ b/test/T355-smime.sh
@@ -134,7 +134,6 @@ OpenPGP Example Corp"
test_expect_equal "$expected" "$output"
test_begin_subtest "reply to PKCS#7 SignedData message with proper quoting and
attribution"
-test_subtest_known_broken
output=$(notmuch reply id:smime-onepart-signed@protected-headers.example)
expected="From: Notmuch Test Suite
Subject: Re: The FooCorp contract
--
2.24.0
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 10/14] cli: include wrapped part of PKCS#7 SignedData in the MIME tree
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| 23 +--
test/T355-smime.sh | 2 +-
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/mime-node.c b/mime-node.c
index ff6805bf..b6431e3b 100644
--- a/mime-node.c
+++ b/mime-node.c
@@ -220,8 +220,17 @@ node_verify (mime_node_t *node, GMimeObject *part)
notmuch_status_t status;
node->verify_attempted = true;
-node->sig_list = g_mime_multipart_signed_verify (
- GMIME_MULTIPART_SIGNED (part), GMIME_VERIFY_NONE, );
+if (GMIME_IS_APPLICATION_PKCS7_MIME (part))
+ node->sig_list = g_mime_application_pkcs7_mime_verify (
+ GMIME_APPLICATION_PKCS7_MIME (part), GMIME_VERIFY_NONE,
>unwrapped_child, );
+else
+ node->sig_list = g_mime_multipart_signed_verify (
+ GMIME_MULTIPART_SIGNED (part), GMIME_VERIFY_NONE, );
+
+if (node->unwrapped_child) {
+ node->nchildren = 1;
+ set_unwrapped_child_destructor (node);
+}
if (node->sig_list)
set_signature_list_destructor (node);
@@ -376,6 +385,12 @@ _mime_node_set_up_part (mime_node_t *node, GMimeObject
*part, int numchild)
} else {
node_verify (node, part);
}
+} else if (GMIME_IS_APPLICATION_PKCS7_MIME (part) &&
+ GMIME_SECURE_MIME_TYPE_SIGNED_DATA ==
g_mime_application_pkcs7_mime_get_smime_type (GMIME_APPLICATION_PKCS7_MIME
(part))) {
+ /* If node->ctx->crypto->verify is false, it would be better
+* to just unwrap (instead of verifying), but
+* https://github.com/jstedfast/gmime/issues/67 */
+ node_verify (node, part);
} else {
if (_notmuch_message_crypto_potential_payload (node->ctx->msg_crypto,
part, node->parent ? node->parent->part : NULL, numchild) &&
node->ctx->msg_crypto->decryption_status ==
NOTMUCH_MESSAGE_DECRYPTED_FULL) {
@@ -409,6 +424,10 @@ mime_node_child (mime_node_t *parent, int child)
GMIME_MULTIPART (parent->part), child);
} else if (GMIME_IS_MESSAGE (parent->part)) {
sub = g_mime_message_get_mime_part (GMIME_MESSAGE (parent->part));
+} else if (GMIME_IS_APPLICATION_PKCS7_MIME (parent->part) &&
+ parent->unwrapped_child &&
+ child == 0) {
+ sub = parent->unwrapped_child;
} else {
/* This should have been caught by _mime_node_set_up_part */
INTERNAL_ERROR ("Unexpected GMimeObject type: %s",
diff --git a/test/T355-smime.sh b/test/T355-smime.sh
index 32fdd9dc..2b74918f 100755
--- a/test/T355-smime.sh
+++ b/test/T355-smime.sh
@@ -120,7 +120,6 @@ expected='#notmuch-dump batch-tag:3 config,properties,tags
test_expect_equal "$expected" "$output"
test_begin_subtest "show contents of PKCS#7 SignedData message"
-test_subtest_known_broken
output=$(notmuch show --format=raw --part=2
id:smime-onepart-signed@protected-headers.example)
whitespace=' '
expected="Bob, we need to cancel this contract.
@@ -156,6 +155,7 @@ On Tue, 26 Nov 2019 20:11:29 -0400, Alice Lovelace
wrote:
test_expect_equal "$expected" "$output"
test_begin_subtest "show PKCS#7 SignedData outputs valid JSON"
+test_subtest_known_broken
output=$(notmuch show --format=json
id:smime-onepart-signed@protected-headers.example)
test_valid_json "$output"
--
2.24.0
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Handle PKCS#7 signedData (S/MIME single-part clearsigned)
PKCS#7 is the binary format used by Cryptographic Message Syntax (CMS). S/MIME (RFC 8551) specifies a number of different "smime-type" PKCS#7 wrapping layers. Until now, notmuch has only handled multipart/signed PKCS#7 clearsigned messages. But S/MIME has another form of clearsigned message named "signedData" (or as the smime-type parameter writes it "signed-data"). This type of clearsigned message can transit through mangling MTAs slightly better than multipart/signed, because an S/MIME-ignorant MTA will treat it as an opaque blob. This avoids the scenario where a legacy MTA tampers with the body of a multipart/signed message in violation of §3 of RFC 1847, breaking the signature. However, PKCS#7 signedData objects are also opaque to legacy (S/MIME-ignorant) MUAs, which can't read the contents of the clearsigned message because they don't know how to unpack the PKCS#7. notmuch is currently such a legacy MUA, but this series will change that, giving notmuch the ability to read the contents of (and verify the signatures on) PKCS#7 signedData parts. Note that this series does not yet handle PKCS#7 envelopedData or authEnvelopedData (the S/MIME encryption layers, which differ only in ciphertext malleability), and it also does not handle compressedData. The framework it puts in place should be useful in handling those kinds of additional S/MIME layers, as long as GMime is capable of handling them. But the series is long enough without adding that additional complexity, and I'd love to get some review of it before i carry on working on the decryption parts. The series starts with a small number of cleanup/framing patches, then adds a sample S/MIME signedData message and a bunch of known-broken tests, then proceeds to fix each of the tests. Several of the patches should be simple to read and uncontroversial (I hope!), and I welcome/encourage merging of those patches to reduce the length of the remaining series. As always, feedback and critique and questions are welcome :) --dkg ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 01/14] mime-node: Pass the correct flags to g_mime_multipart_signed_verify
GMIME_ENCRYPT_NONE and GMIME_VERIFY_NONE have the same value, but they are different enumerated types. So in C, this is a cosmetic change, but it is technically correct if we only had stricter typing. Signed-off-by: Daniel Kahn Gillmor --- mime-node.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mime-node.c b/mime-node.c index d4996a33..e531078c 100644 --- a/mime-node.c +++ b/mime-node.c @@ -201,7 +201,7 @@ node_verify (mime_node_t *node, GMimeObject *part) node->verify_attempted = true; node->sig_list = g_mime_multipart_signed_verify ( - GMIME_MULTIPART_SIGNED (part), GMIME_ENCRYPT_NONE, ); + GMIME_MULTIPART_SIGNED (part), GMIME_VERIFY_NONE, ); if (node->sig_list) set_signature_list_destructor (node); -- 2.24.0 ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 02/14] tests/smime: Always use --batch with gpgsm
GnuPG's gpgsm, like gpg, should always be used with --batch when it is
invoked in a non-interactive environment.
Signed-off-by: Daniel Kahn Gillmor
---
test/T355-smime.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/test/T355-smime.sh b/test/T355-smime.sh
index 336da917..c272533a 100755
--- a/test/T355-smime.sh
+++ b/test/T355-smime.sh
@@ -10,8 +10,8 @@ add_gpgsm_home ()
_gnupg_exit () { gpgconf --kill all 2>/dev/null || true; }
at_exit_function _gnupg_exit
mkdir -m 0700 "$GNUPGHOME"
-gpgsm --no-tty --no-common-certs-import --disable-dirmngr --import <
$NOTMUCH_SRCDIR/test/smime/test.crt >"$GNUPGHOME"/import.log 2>&1
-fpr=$(gpgsm --list-key test_su...@notmuchmail.org | sed -n
's/.*fingerprint: //p')
+gpgsm --batch --no-tty --no-common-certs-import --disable-dirmngr --import
< $NOTMUCH_SRCDIR/test/smime/test.crt >"$GNUPGHOME"/import.log 2>&1
+fpr=$(gpgsm --batch --list-key test_su...@notmuchmail.org | sed -n
's/.*fingerprint: //p')
echo "$fpr S relax" >> $GNUPGHOME/trustlist.txt
test_debug "cat $GNUPGHOME/import.log"
}
--
2.24.0
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 07/14] lib: index PKCS7 SignedData parts
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 unwrap without doing signature verification.
I've opened https://github.com/jstedfast/gmime/issues/67 to request
the capability from GMime but for now, we'll just accept the
additional performance hit.
As we do this indexing, we also apply the "signed" tag, by analogy
with how we handle multipart/signed messages. These days, that kind
of change should probably be done with a property instead, but that's
a different set of changes. This one is just for consistency.
Note that we are currently *only* handling signedData parts, which are
basically clearsigned messages. PKCS#7 parts can also be
envelopedData and authEnvelopedData (which are effectively encryption
layers), and compressedData (which afaict isn't implemented anywhere,
i've never encountered it). We're laying the groundwork for indexing
these other S/MIME types here, but we're only dealing with signedData
for now.
Signed-off-by: Daniel Kahn Gillmor
---
lib/index.cc | 57 ++
test/T355-smime.sh | 2 --
2 files changed, 57 insertions(+), 2 deletions(-)
diff --git a/lib/index.cc b/lib/index.cc
index 158ba5cf..bbf13dc5 100644
--- a/lib/index.cc
+++ b/lib/index.cc
@@ -372,6 +372,12 @@ _index_encrypted_mime_part (notmuch_message_t *message,
notmuch_indexopts_t *ind
GMimeMultipartEncrypted *part,
_notmuch_message_crypto_t *msg_crypto);
+static void
+_index_pkcs7_part (notmuch_message_t *message,
+ notmuch_indexopts_t *indexopts,
+ GMimeObject *part,
+ _notmuch_message_crypto_t *msg_crypto);
+
/* Callback to generate terms for each mime part of a message. */
static void
_index_mime_part (notmuch_message_t *message,
@@ -466,6 +472,11 @@ _index_mime_part (notmuch_message_t *message,
goto DONE;
}
+if (GMIME_IS_APPLICATION_PKCS7_MIME (part)) {
+ _index_pkcs7_part (message, indexopts, part, msg_crypto);
+ goto DONE;
+}
+
if (! (GMIME_IS_PART (part))) {
_notmuch_database_log (notmuch_message_get_database (message),
"Warning: Not indexing unknown mime part: %s.\n",
@@ -608,6 +619,52 @@ _index_encrypted_mime_part (notmuch_message_t *message,
}
+static void
+_index_pkcs7_part (notmuch_message_t *message,
+ notmuch_indexopts_t *indexopts,
+ GMimeObject *part,
+ _notmuch_message_crypto_t *msg_crypto)
+{
+GMimeApplicationPkcs7Mime *pkcs7;
+GMimeSecureMimeType p7type;
+GMimeObject *mimeobj = NULL;
+GMimeSignatureList *sigs = NULL;
+GError *err = NULL;
+notmuch_database_t *notmuch = NULL;
+
+pkcs7 = GMIME_APPLICATION_PKCS7_MIME (part);
+p7type = g_mime_application_pkcs7_mime_get_smime_type (pkcs7);
+notmuch = notmuch_message_get_database (message);
+_index_content_type (message, part);
+
+if (p7type == GMIME_SECURE_MIME_TYPE_SIGNED_DATA) {
+ sigs = g_mime_application_pkcs7_mime_verify (pkcs7, GMIME_VERIFY_NONE,
, );
+ if (sigs == NULL) {
+ _notmuch_database_log (notmuch, "Failed to verify PKCS#7 SignedData
during indexing. (%d:%d) [%s]\n",
+ err->domain, err->code, err->message);
+ g_error_free (err);
+ goto DONE;
+ }
+ _notmuch_message_add_term (message, "tag", "signed");
+ GMimeObject *toindex = mimeobj;
+ if (_notmuch_message_crypto_potential_payload (msg_crypto, mimeobj,
part, 0) &&
+ msg_crypto->decryption_status == NOTMUCH_MESSAGE_DECRYPTED_FULL) {
+ toindex = _notmuch_repair_crypto_payload_skip_legacy_display
(mimeobj);
+ if (toindex != mimeobj)
+ notmuch_message_add_property (message, "index.repaired",
"skip-protected-headers-legacy-display");
+ }
+ _index_mime_part (message, indexopts, toindex, msg_crypto);
+} else {
+ _notmuch_database_log (notmuch, "Cannot currently handle PKCS#7
smime-type '%s'\n",
+ g_mime_object_get_content_type_parameter (part,
"smime-type"));
+}
+ DONE:
+if (mimeobj)
+ g_object_unref (mimeobj);
+if (sigs)
+ g_object_unref (sigs);
+}
+
static notmuch_status_t
_notmuch_message_index_user_headers (notmuch_message_t *message, GMimeMessage
*mime_message)
{
diff --git a/test/T355-smime.sh b/test/T355-smime.sh
index 9055e589..32fdd9dc 100755
--- a/test/T355-smime.sh
+++ b/test/T355-smime.sh
@@ -109,13 +109,11 @@ expected=''
test_expect_equal "$expected" "$output"
test_begin_subtest "know the MIME type of the embedded part in PKCS#7
SignedData"
-test_subtest_known_broken
[PATCH 11/14] cli/show: If a leaf part has children, show them instead of omitting
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.
Signed-off-by: Daniel Kahn Gillmor
---
notmuch-show.c | 11 ++-
test/T355-smime.sh | 1 -
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/notmuch-show.c b/notmuch-show.c
index 21792a57..c809f8e9 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -759,7 +759,16 @@ format_part_sprinter (const void *ctx, sprinter_t *sp,
mime_node_t *node,
sp->string_len (sp, (char *) part_content->data, part_content->len);
g_object_unref (stream_memory);
} else {
- format_omitted_part_meta_sprinter (sp, meta, GMIME_PART
(node->part));
+ /* if we have a child part despite being a standard
+* (non-multipart) MIME part, that means there is
+* something to unwrap, which we will present in
+* content: */
+ if (node->nchildren) {
+ sp->map_key (sp, "content");
+ sp->begin_list (sp);
+ nclose = 1;
+ } else
+ format_omitted_part_meta_sprinter (sp, meta, GMIME_PART
(node->part));
}
} else if (GMIME_IS_MULTIPART (node->part)) {
sp->map_key (sp, "content");
diff --git a/test/T355-smime.sh b/test/T355-smime.sh
index 2b74918f..399bd91c 100755
--- a/test/T355-smime.sh
+++ b/test/T355-smime.sh
@@ -155,7 +155,6 @@ On Tue, 26 Nov 2019 20:11:29 -0400, Alice Lovelace
wrote:
test_expect_equal "$expected" "$output"
test_begin_subtest "show PKCS#7 SignedData outputs valid JSON"
-test_subtest_known_broken
output=$(notmuch show --format=json
id:smime-onepart-signed@protected-headers.example)
test_valid_json "$output"
--
2.24.0
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 08/14] mime-node: rename decrypted_child to unwrapped_child
When walking the MIME tree, we might need to extract a new MIME
object. Thus far, we've only done it when decrypting
multipart/encrypted messages, but PKCS#7 (RFC 8551, S/MIME) has
several other transformations that warrant a comparable form of
unwrapping.
Make this member re-usable for PKCS#7 unwrappings as well as
multipart/encrypted decryptions.
This change is just a naming change, it has no effect on function.
Signed-off-by: Daniel Kahn Gillmor
---
mime-node.c | 10 +-
notmuch-client.h | 6 --
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/mime-node.c b/mime-node.c
index e531078c..2a823dfd 100644
--- a/mime-node.c
+++ b/mime-node.c
@@ -227,19 +227,19 @@ node_decrypt_and_verify (mime_node_t *node, GMimeObject
*part)
GMimeMultipartEncrypted *encrypteddata = GMIME_MULTIPART_ENCRYPTED (part);
notmuch_message_t *message = NULL;
-if (! node->decrypted_child) {
+if (! node->unwrapped_child) {
for (mime_node_t *parent = node; parent; parent = parent->parent)
if (parent->envelope_file) {
message = parent->envelope_file;
break;
}
- node->decrypted_child = _notmuch_crypto_decrypt
(>decrypt_attempted,
+ node->unwrapped_child = _notmuch_crypto_decrypt
(>decrypt_attempted,
node->ctx->crypto->decrypt,
message,
encrypteddata,
_result, );
}
-if (! node->decrypted_child) {
+if (! node->unwrapped_child) {
fprintf (stderr, "Failed to decrypt part: %s\n",
err ? err->message : "no error explanation given");
goto DONE;
@@ -380,8 +380,8 @@ mime_node_child (mime_node_t *parent, int child)
return NULL;
if (GMIME_IS_MULTIPART (parent->part)) {
- if (child == GMIME_MULTIPART_ENCRYPTED_CONTENT &&
parent->decrypted_child)
- sub = parent->decrypted_child;
+ if (child == GMIME_MULTIPART_ENCRYPTED_CONTENT &&
parent->unwrapped_child)
+ sub = parent->unwrapped_child;
else
sub = g_mime_multipart_get_part (
GMIME_MULTIPART (parent->part), child);
diff --git a/notmuch-client.h b/notmuch-client.h
index 74690054..89e15ba6 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -395,8 +395,10 @@ struct mime_node {
struct mime_node_context *ctx;
/* Internal: For successfully decrypted multipart parts, the
- * decrypted part to substitute for the second child. */
-GMimeObject *decrypted_child;
+ * decrypted part to substitute for the second child; or, for
+ * PKCS#7 parts, the part returned after removing/processing the
+ * PKCS#7 transformation */
+GMimeObject *unwrapped_child;
/* Internal: The next child for depth-first traversal and the part
* number to assign it (or -1 if unknown). */
--
2.24.0
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 05/14] test-lib.sh: add test_valid_json
This test does exactly what it says on the tin. It expects JSON data
to be parseable by Python, at least.
Signed-off-by: Daniel Kahn Gillmor
---
test/test-lib.sh | 6 ++
1 file changed, 6 insertions(+)
diff --git a/test/test-lib.sh b/test/test-lib.sh
index 7f8a3a4d..a54ae40f 100644
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -503,6 +503,12 @@ test_expect_equal_json () {
test_expect_equal "$output" "$expected" "$@"
}
+# Ensure that the argument is valid JSON data.
+test_valid_json () {
+PYTHONIOENCODING=utf-8 $NOTMUCH_PYTHON -c "import sys, json;
json.load(sys.stdin)" <<<"$1"
+test_expect_equal "$?" 0
+}
+
# Sort the top-level list of JSON data from stdin.
test_sort_json () {
PYTHONIOENCODING=utf-8 $NOTMUCH_PYTHON -c \
--
2.24.0
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 04/14] tests/smime: consistently quote $GNUPGHOME
Signed-off-by: Daniel Kahn Gillmor
---
test/T355-smime.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/test/T355-smime.sh b/test/T355-smime.sh
index dac9b1e5..cbd3e5a6 100755
--- a/test/T355-smime.sh
+++ b/test/T355-smime.sh
@@ -6,13 +6,13 @@ test_description='S/MIME signature verification and
decryption'
add_gpgsm_home ()
{
local fpr
-[ -d ${GNUPGHOME} ] && return
+[ -d "$GNUPGHOME" ] && return
_gnupg_exit () { gpgconf --kill all 2>/dev/null || true; }
at_exit_function _gnupg_exit
mkdir -m 0700 "$GNUPGHOME"
gpgsm --batch --no-tty --no-common-certs-import --disable-dirmngr --import
< $NOTMUCH_SRCDIR/test/smime/test.crt >"$GNUPGHOME"/import.log 2>&1
fpr=$(gpgsm --batch --list-key test_su...@notmuchmail.org | sed -n
's/.*fingerprint: //p')
-echo "$fpr S relax" >> $GNUPGHOME/trustlist.txt
+echo "$fpr S relax" >> "$GNUPGHOME/trustlist.txt"
gpgsm --quiet --batch --no-tty --no-common-certs-import --disable-dirmngr
--import < $NOTMUCH_SRCDIR/test/smime/ca.crt
echo "4D:E0:FF:63:C0:E9:EC:01:29:11:C8:7A:EE:DA:3A:9A:7F:6E:C1:0D S" >>
"$GNUPGHOME/trustlist.txt"
test_debug "cat $GNUPGHOME/import.log"
--
2.24.0
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 13/14] cli: sprinter should be able to print an unsigned long
In some circumstances, we will encounter an unsigned long, and need to
emit it textually.
For example, in GPGME, the gpgme_signature_t object has members
(`created` and `expires`) that are unsigned long integers. notmuch
doesn't use GPGME directly, but subsequent changes will make it clear
why we need to do have this capability.
Signed-off-by: Daniel Kahn Gillmor
---
sprinter-json.c | 9 +
sprinter-sexp.c | 9 +
sprinter-text.c | 9 +
sprinter.h | 1 +
4 files changed, 28 insertions(+)
diff --git a/sprinter-json.c b/sprinter-json.c
index c6ec8577..0fc734f7 100644
--- a/sprinter-json.c
+++ b/sprinter-json.c
@@ -131,6 +131,14 @@ json_integer (struct sprinter *sp, int val)
fprintf (spj->stream, "%d", val);
}
+static void
+json_ulong (struct sprinter *sp, unsigned long val)
+{
+struct sprinter_json *spj = json_begin_value (sp);
+
+fprintf (spj->stream, "%lu", val);
+}
+
static void
json_boolean (struct sprinter *sp, bool val)
{
@@ -181,6 +189,7 @@ sprinter_json_create (const void *ctx, FILE *stream)
.string = json_string,
.string_len = json_string_len,
.integer = json_integer,
+ .ulong = json_ulong,
.boolean = json_boolean,
.null = json_null,
.map_key = json_map_key,
diff --git a/sprinter-sexp.c b/sprinter-sexp.c
index 6891ea42..72f23f4d 100644
--- a/sprinter-sexp.c
+++ b/sprinter-sexp.c
@@ -168,6 +168,14 @@ sexp_integer (struct sprinter *sp, int val)
fprintf (sps->stream, "%d", val);
}
+static void
+sexp_ulong (struct sprinter *sp, unsigned long val)
+{
+struct sprinter_sexp *sps = (struct sprinter_sexp *) sp;
+
+fprintf (sps->stream, "%lu", val);
+}
+
static void
sexp_boolean (struct sprinter *sp, bool val)
{
@@ -216,6 +224,7 @@ sprinter_sexp_create (const void *ctx, FILE *stream)
.string = sexp_string,
.string_len = sexp_string_len,
.integer = sexp_integer,
+ .ulong = sexp_ulong,
.boolean = sexp_boolean,
.null = sexp_null,
.map_key = sexp_map_key,
diff --git a/sprinter-text.c b/sprinter-text.c
index 648b54b1..2c6f635e 100644
--- a/sprinter-text.c
+++ b/sprinter-text.c
@@ -51,6 +51,14 @@ text_integer (struct sprinter *sp, int val)
fprintf (sptxt->stream, "%d", val);
}
+static void
+text_ulong (struct sprinter *sp, unsigned long val)
+{
+struct sprinter_text *sptxt = (struct sprinter_text *) sp;
+
+fprintf (sptxt->stream, "%lu", val);
+}
+
static void
text_boolean (struct sprinter *sp, bool val)
{
@@ -123,6 +131,7 @@ sprinter_text_create (const void *ctx, FILE *stream)
.string = text_string,
.string_len = text_string_len,
.integer = text_integer,
+ .ulong = text_ulong,
.boolean = text_boolean,
.null = text_null,
.map_key = text_map_key,
diff --git a/sprinter.h b/sprinter.h
index 182b1a8b..3c23d718 100644
--- a/sprinter.h
+++ b/sprinter.h
@@ -34,6 +34,7 @@ typedef struct sprinter {
void (*string)(struct sprinter *, const char *);
void (*string_len)(struct sprinter *, const char *, size_t);
void (*integer)(struct sprinter *, int);
+void (*ulong)(struct sprinter *, unsigned long);
void (*boolean)(struct sprinter *, bool);
void (*null)(struct sprinter *);
--
2.24.0
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 03/14] tests/smime: Include the Sample LAMPS Certificate Authority
This CA is useful for test suites and the like, but is not an actually-secure CA, because its secret key material is also published. I plan to use it for its intended purpose in the notmuch test suite. It was copied from this Internet Draft: https://www.ietf.org/id/draft-dkg-lamps-samples-01.html#name-certificate-authority-certi Signed-off-by: Daniel Kahn Gillmor --- test/T355-smime.sh | 2 ++ test/smime/README | 2 ++ test/smime/ca.crt | 20 3 files changed, 24 insertions(+) create mode 100644 test/smime/ca.crt diff --git a/test/T355-smime.sh b/test/T355-smime.sh index c272533a..dac9b1e5 100755 --- a/test/T355-smime.sh +++ b/test/T355-smime.sh @@ -13,6 +13,8 @@ add_gpgsm_home () gpgsm --batch --no-tty --no-common-certs-import --disable-dirmngr --import < $NOTMUCH_SRCDIR/test/smime/test.crt >"$GNUPGHOME"/import.log 2>&1 fpr=$(gpgsm --batch --list-key test_su...@notmuchmail.org | sed -n 's/.*fingerprint: //p') echo "$fpr S relax" >> $GNUPGHOME/trustlist.txt +gpgsm --quiet --batch --no-tty --no-common-certs-import --disable-dirmngr --import < $NOTMUCH_SRCDIR/test/smime/ca.crt +echo "4D:E0:FF:63:C0:E9:EC:01:29:11:C8:7A:EE:DA:3A:9A:7F:6E:C1:0D S" >> "$GNUPGHOME/trustlist.txt" test_debug "cat $GNUPGHOME/import.log" } diff --git a/test/smime/README b/test/smime/README index 92803c77..6b8d3f87 100644 --- a/test/smime/README +++ b/test/smime/README @@ -5,3 +5,5 @@ key+cert.pem: cert + unencryped private % gpsm --import test.crt % gpgsm --export-private-key-p12 -out foo.p12 (no passphrase) % openssl pkcs12 -in ns.p12 -clcerts -nodes > key+cert.pem + +ca.crt: from https://www.ietf.org/id/draft-dkg-lamps-samples-01.html#name-certificate-authority-certi diff --git a/test/smime/ca.crt b/test/smime/ca.crt new file mode 100644 index ..b33d087f --- /dev/null +++ b/test/smime/ca.crt @@ -0,0 +1,20 @@ +-BEGIN CERTIFICATE- +MIIDLTCCAhWgAwIBAgIULXcNXGI2bZp38sV7cF6VcQfnKDwwDQYJKoZIhvcNAQEN +BQAwLTErMCkGA1UEAxMiU2FtcGxlIExBTVBTIENlcnRpZmljYXRlIEF1dGhvcml0 +eTAgFw0xOTExMjAwNjU0MThaGA8yMDUyMDkyNzA2NTQxOFowLTErMCkGA1UEAxMi +U2FtcGxlIExBTVBTIENlcnRpZmljYXRlIEF1dGhvcml0eTCCASIwDQYJKoZIhvcN +AQEBBQADggEPADCCAQoCggEBAMUfZ8+NYSh6h36zQcXBo5B6ficAcBJ1f3aLxyN8 +QXB83XuP8aDRWQ9uJvJpQkWVH4zx96/E/zI0t0lDMYtZNqra16h+gxbHJgoq2pRw +RCOiyYu/p2vzvvZ1dtFTMc/mIigjA/73kokui62j1EFy//fNVIihkVS3rAweq+fI +8qJHSMhdc2aYa9wOP0eGe/HTiDYgT4L4f2HTGMGGwQgj1vub0gpR4YHmNqr0GyEA +63mHUQUZpnmN1FEl+nVFA5Ntu4uF++qf/tkTji89/eXYBdKX2yUdTeTIKoCI65IL +EXxezjTc8aFjf/8E0aWGVZR/DtCsjWOh/s/mV7n/YPyb4+ECAwEAAaNDMEEwDwYD +VR0TAQH/BAUwAwEB/zAPBgNVHQ8BAf8EBQMDBwYAMB0GA1UdDgQWBBS3Uk1zwIg9 +ssN6WgzzlPf3gKJ32zANBgkqhkiG9w0BAQ0FAAOCAQEALsU91Bmhc6EgCNr7inY2 +2gYPnosJ+kZ1eC0hvHIK9e0Tx74RmhTOe8M2C9YXQKehHpRaX+DLcjup6scoH/bT +u0THbmzeOy29TTiFcyV9BK+SEKQWW4s98Fwdk9fPWcflHtYvqxjooAV3vHbt6Xmp +KrKDz/jdg7t0ptI4zSqAf3wNppiJoswlOHBUnH2W1MIYkWQ4jYj5socblVlklHOr +ykKUiEZAbjU+C1+0FhT4HgLjBB9R4H1H0JRKsggWiZBBJ6UpN0dTN4iD0mDVa0jy +sJqqWnIViy/xaSDcNaWJmU3o2KmkMkdpinoJ5uLkAHQqXjFaujdU1PkufeA7v3uG +Rw== +-END CERTIFICATE- -- 2.24.0 ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 14/14] cli: Avoid bogus signature dates from GMime
As noted in https://github.com/jstedfast/gmime/issues/68, GMime
converts the unsigned longs returned from GPGME into time_t objects.
On architectures with a signed 32-bit time_t (like GNU/Linux x86_64),
this means that we're limited to 31 bits of data, which means the
clock wraps around in 2038.
Until GMime fixes this properly, we can regain 1 bit of space by
casting back from time_t to an unsigned long. This gives us a window
of up until early 2106.
The example S/MIME SignedData message is signed by a certificate whose
expiration date is Fri Sep 27 06:54:18 UTC 2052 (2611032858 seconds
since the epoch). GPGME reports the value faithfully as the
expiration date of the signature on this message, but GMime wraps it
back around to the negative.
Once GMime fixes #68, we should transition to their upstream fix
instead of maintaining this workaround forever.
Signed-off-by: Daniel Kahn Gillmor
---
notmuch-show.c | 4 ++--
test/T355-smime.sh | 1 -
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/notmuch-show.c b/notmuch-show.c
index c809f8e9..84839180 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -447,12 +447,12 @@ format_part_sigstatus_sprinter (sprinter_t *sp,
GMimeSignatureList *siglist)
time_t created = g_mime_signature_get_created (signature);
if (created != -1) {
sp->map_key (sp, "created");
- sp->integer (sp, created);
+ sp->ulong (sp, (unsigned long) created);
}
time_t expires = g_mime_signature_get_expires (signature);
if (expires > 0) {
sp->map_key (sp, "expires");
- sp->integer (sp, expires);
+ sp->ulong (sp, (unsigned long) expires);
}
if (certificate) {
const char *uid = g_mime_certificate_get_valid_userid
(certificate);
diff --git a/test/T355-smime.sh b/test/T355-smime.sh
index ddc91a56..dedf5ab1 100755
--- a/test/T355-smime.sh
+++ b/test/T355-smime.sh
@@ -158,7 +158,6 @@ output=$(notmuch show --format=json
id:smime-onepart-sig...@protected-headers.ex
test_valid_json "$output"
test_begin_subtest "Verify signature on PKCS#7 SignedData message"
-test_subtest_known_broken
output=$(notmuch show --format=json
id:smime-onepart-signed@protected-headers.example)
test_json_nodes <<<"$output" \
'crypto:[0][0][0]["crypto"]["signed"]["status"][0]={
--
2.24.0
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: possibly outdated info on notmuch website(?)
Gregor Zattler writes: > Dear notmuch developers, > > https://notmuchmail.org/#index8h2 > > states among other things: > > Another mailing list > > Currently the mailing list at notmuchmail.org is not working > much, so we have a temporary (?) list at freelists.org. Feel > free to subscribe if you like, and to CC both lists with > problem reports. > > since the most current archive on freelists.org ist for 04-2019 I > assume this is info is dated and should be deleted. Yes, the list should probably be archived or something, it's not active these days. A note to that effect would make sense. See https://notmuchmail.org/wikiwriteaccess/ for how to update the wiki. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 3/6] Move to dh 12
Daniel Kahn Gillmor writes: > On Tue 2019-12-03 08:10:44 -0400, David Bremner wrote: >> Daniel Kahn Gillmor writes: >> >>> Signed-off-by: Daniel Kahn Gillmor >>> --- >>> debian/compat | 1 - >>> debian/control | 2 +- >>> 2 files changed, 1 insertion(+), 2 deletions(-) >>> delete mode 100644 debian/compat >> >> This change introduces a large number of warnings from dh_missing. I >> guess this is because we install some things as upstream, and also in >> debian specific ways. I'd rather not introduce 75 lines of warnings into >> the build log at the moment. Do you want to rebase the series without >> this patch, or some solution? We can add the files to >> debian/not-installed, but that feels a bit ugly (and also technical >> debt, since that file will get out of date) > > I think what you're saying is that we *do* have the technical debt > already (in that we're not keeping track of what gets installed in a way > that dh knows about, vs. getting installed manually), and this patch > just exposes it :) > > If you'd rather skip this for now and merge the rest of the series, i'm > happy to look into reducing the number of warnings later. > I've merged all except this patch, and the wrap-and-sort. No real objection to the latter, but it is too painful to rebase, and will need regeneration. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] configure: Install zsh completions where zsh will find them.
Oliver Kiddle writes: > Zsh searches in the $fpath array for completion functions. By default > this includes $(prefix)/share/zsh/site-functions but not the existing > value. The prefix for zsh and notmuch isn't guaranteed to be the same > but it normally will be making this a better default for > zsh_completion_dir. Merged to git master. thanks, d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [BUG] notmuch-emacs: spoils sendmail -f with emacs 27 commit 3a59cc84069376802ba8fd731b524d78db58262c and later
On Tuesday, 2019-12-03 at 15:39:47 -05, Stefan Monnier wrote:
>> disaster-area ~/s/emacs % ./src/emacs -Q -nw -batch --eval "(progn (require
>> 'message) (setq mail-specify-envelope-from t mail-envelope-from 'header)
>> (message \"%s\" message-sendmail-envelope-from))"
>> nil
>> disaster-area ~/s/emacs %
>
> Ha! Thanks for tracking it down.
>
> I installed the patch below into `master` to try and avoid this problem.
>
>
> Stefan
>
>
> diff --git a/lisp/gnus/message.el b/lisp/gnus/message.el
> index f33454e704..e60ea4f0e8 100644
> --- a/lisp/gnus/message.el
> +++ b/lisp/gnus/message.el
> @@ -854,18 +854,24 @@ message-sendmail-f-is-evil
>:type 'boolean)
>
> (defcustom message-sendmail-envelope-from
> - ;; `mail-envelope-from' is unavailable unless sendmail.el is loaded.
> - (if (boundp 'mail-envelope-from) mail-envelope-from)
> + 'obey-mail-envelope-from
>"Envelope-from when sending mail with sendmail.
> If this is nil, use `user-mail-address'. If it is the symbol
> `header', use the From: header of the message."
> - :version "23.2"
> + :version "27.1"
>:type '(choice (string :tag "From name")
>(const :tag "Use From: header from message" header)
> + (const :tag "Obey `sendmail-envelope-from'"
`sendmail-envelope-from' here should be `mail-envelope-from'.
> + obey-mail-envelope-from)
>(const :tag "Use `user-mail-address'" nil))
>:link '(custom-manual "(message)Mail Variables")
>:group 'message-sending)
>
> +(defun message--sendmail-envelope-from ()
> + (if (eq message-sendmail-envelope-from 'obey-mail-envelope-from)
> + (if (boundp 'mail-envelope-from) mail-envelope-from)
> +message-sendmail-envelope-from))
> +
> (defcustom message-sendmail-extra-arguments nil
>"Additional arguments to `sendmail-program'."
>;; E.g. '("-a" "account") for msmtp
> @@ -5884,11 +5890,11 @@ message-user-mail-address
>
> (defun message-sendmail-envelope-from ()
>"Return the envelope from."
> - (cond ((eq message-sendmail-envelope-from 'header)
> + (cond ((eq (message--sendmail-envelope-from) 'header)
>(nth 1 (mail-extract-address-components
>(message-fetch-field "from"
> - ((stringp message-sendmail-envelope-from)
> - message-sendmail-envelope-from)
> + ((stringp (message--sendmail-envelope-from))
> + (message--sendmail-envelope-from))
> (t
>(message-make-address
>
> diff --git a/lisp/mail/emacsbug.el b/lisp/mail/emacsbug.el
> index 1c2f11680b..fea7619b50 100644
> --- a/lisp/mail/emacsbug.el
> +++ b/lisp/mail/emacsbug.el
> @@ -239,8 +239,8 @@ report-emacs-bug
>;; Stop message-mode stealing the properties we will add.
>(set (make-local-variable 'message-strip-special-text-properties) nil)
>;; Make sure we default to the From: address as envelope when sending
> - ;; through sendmail.
> - (when (and (not message-sendmail-envelope-from)
> + ;; through sendmail. FIXME: Why?
> + (when (and (not (message--sendmail-envelope-from))
>(message-bogus-recipient-p (message-make-address)))
> (set (make-local-variable 'message-sendmail-envelope-from) 'header)))
> (rfc822-goto-eoh)
dme.
--
But are you safe Miss Gradenko?
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 3/6] Move to dh 12
On Tue 2019-12-03 08:10:44 -0400, David Bremner wrote: > Daniel Kahn Gillmor writes: > >> Signed-off-by: Daniel Kahn Gillmor >> --- >> debian/compat | 1 - >> debian/control | 2 +- >> 2 files changed, 1 insertion(+), 2 deletions(-) >> delete mode 100644 debian/compat > > This change introduces a large number of warnings from dh_missing. I > guess this is because we install some things as upstream, and also in > debian specific ways. I'd rather not introduce 75 lines of warnings into > the build log at the moment. Do you want to rebase the series without > this patch, or some solution? We can add the files to > debian/not-installed, but that feels a bit ugly (and also technical > debt, since that file will get out of date) I think what you're saying is that we *do* have the technical debt already (in that we're not keeping track of what gets installed in a way that dh knows about, vs. getting installed manually), and this patch just exposes it :) If you'd rather skip this for now and merge the rest of the series, i'm happy to look into reducing the number of warnings later. But in general, i'm not scared of introducing those warnings first -- hopefully having the warnings present will encourage someone™ to fix them! --dkg signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [BUG] notmuch-emacs: spoils sendmail -f with emacs 27 commit 3a59cc84069376802ba8fd731b524d78db58262c and later
On Tuesday, 2019-12-03 at 20:15:02 +01, Gregor Zattler wrote: >> As best I can determine, this relates to the order in which things are >> loaded. >> >> If you load message.el before setting `mail-specify-envelope-from', >> things are broken (sorry for the long lines): >> >> disaster-area ~/s/emacs % ./src/emacs -Q -nw -batch --eval "(progn (require >> 'message) (setq mail-specify-envelope-from t mail-envelope-from 'header) >> (message \"%s\" message-sendmail-envelope-from))" >> nil >> disaster-area ~/s/emacs % >> >> ...but if you load it after, things work fine: >> >> disaster-area ~/s/emacs % ./src/emacs -Q -nw -batch --eval "(progn (setq >> mail-specify-envelope-from t mail-envelope-from 'header) (require 'message) >> (message \"%s\" message-sendmail-envelope-from))" >> header >> disaster-area ~/s/emacs % >> >> This doesn't appear to be new behaviour - 26.1 does the same. > > this is astonishing, since my test script behaves different with > emacs build with different last commits!? There may well be other layers of complication :-) >> This is related to the way that `message-sendmail-envelope-from' is >> initialised from `mail-envelope-from', and it's >> `message-sendmail-envelope-from' that matters, because you end up in >> `message-send-mail-with-sendmail'. > > At the moment I cannot follow... At least in 27, I don't think that you end up using `sendmail-send-it', because I don't believe that message.el is looking at `send-mail-function'. >> message.el is being loaded by “(require 'notmuch)” in your example, >> which is happening before `mail-specify-envelope-from' is set, so you >> see the failure mode described. > > ... but in my example the setq forms precede every call to > message/notmuch (as in your example)!? That's not the case. Your example is: > ~/src/emacs/src/emacs -Q -nw -L ~/src/notmuch/emacs/ --eval "(require > 'notmuch)" -f notmuch -l /tmp/test.el This loads (via the require) notmuch.el, and consequently message.el, *before* it loads /tmp/test.el, so the setq calls happen after message.el has been loaded. > [And in my emacs configuration the customizations made with emacs' > customization interface (among others the three variables which are > setq in my test script) are loaded before almost anything else, > especially message/notmuch, see below] > >> The example you provided is obviously contrived to show the problem - >> are you hitting it in normal use? > > Absolutely. I struggle with this at least since 2nd of August and have > reproduced this behaviour dozens of times. It took my several > attempts to isolate the problem. > > I use https://github.com/xundeenergie/exim4-multiaccount version > 1.57 as of 2018-06-05 in order to send emails through different > smarthosts. > > I do this every day and with emacs from sources newer than commit > 01739625704aaaea6831cef459a4a53171689513 I'm e.g. not able to send > emails with my work email address ot to this mailing list. This > is especially annoying since sending fails silently. So > relatively important emails as e.g. announcements of downtimes did > not reach their intended audience. > > The whole thing is above my elisp knowledge. Is it possible you > describe something which is not the problem I described? I think that the above explanation applies to the example that you provided here. There may well be a different explanation for what happens with your real configuration. dme. -- I had my eyes closed in the dark. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
possibly outdated info on notmuch website(?)
Dear notmuch developers, https://notmuchmail.org/#index8h2 states among other things: Another mailing list Currently the mailing list at notmuchmail.org is not working much, so we have a temporary (?) list at freelists.org. Feel free to subscribe if you like, and to CC both lists with problem reports. since the most current archive on freelists.org ist for 04-2019 I assume this is info is dated and should be deleted. Ciao; Gregor -- -... --- .-. . -.. ..--.. ...-.- ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [BUG] notmuch-emacs: spoils sendmail -f with emacs 27 commit 3a59cc84069376802ba8fd731b524d78db58262c and later
Hi David, * David Edmondson [2019-12-03; 18:43]: > On Sunday, 2019-12-01 at 18:10:59 +01, Gregor Zattler wrote: >> I use notmuch-emacs configured with >> (setq mail-specify-envelope-from t) >> (setq mail-envelope-from 'header) >> (setq send-mail-function 'sendmail-send-it) >> >> this should/used to invoke sendmail (in my case exim4) with the email >> address given in the From: header of the message buffer as >> argument to sendmails -f option. > > Wow, this was, err, “interesting”. > > Comments below. > >> Since emacs 27 commit 3a59cc84069376802ba8fd731b524d78db58262c >> >> 3a59cc84069376802ba8fd731b524d78db58262c >> Author: Stefan Monnier >> AuthorDate: Tue Jul 30 16:37:01 2019 -0400 >> Commit: Stefan Monnier >> CommitDate: Tue Jul 30 16:37:01 2019 -0400 >> >> Parent: add146f09f * lisp/bindings.el >> (mode-line-defining-kbd-macro): New defvar. >> Contained: master >> Follows:emacs-26.1 (6691) >> >> * lisp/gnus/message.el: Reduce redundancy with send-mail-function >> >> (message-send-mail-function) : Remove `local-library` tests >> for libs distributed with Emacs. >> (message-use-send-mail-function): New function. >> (message-default-send-mail-function): Default to it, and remove cases >> already handled by it. >> (message--default-send-mail-function): New function. >> (message-send-mail-function) : Use it as new default. >> (message-sendmail-f-is-evil): Obey mail-specify-envelope-from if >> available. >> (message-check, message-with-reply-buffer): Use `declare`. >> (message-smtpmail-send-it): smtpmail accepts mail-header-separator, >> so simplify and declare obsolete. >> (message-send-mail-with-mailclient): Declare obsolete. >> (message-check-news-body-syntax): Don't presume that the checksum is >> a fixnum. >> >> >> this actually invokes sendmail -f with an address derived from the >> EMAIL environment variable. >> >> >> It took me some time to understand, that there is no problem with >> compose-mail/message-send-and-exit which are bound to ^X m and ^C >> ^C respectively within a barely configured emacs which I used for >> testing. >> If instead notmuch is loaded compose-mail/message-send-and-exit >> and notmuch-mua-new-mail/notmuch-mua-send behave different. >> >> With this command (with test.el as attached): >> >> ~/src/emacs/src/emacs -Q -nw -l /tmp/test.el >> >> compose-mail/message-send-and-exit rightly show >> -f exam...@example.org in the file /tmp/result (and then there is >> an error because the notmuch commands are not known). >> >> While this command >> >> ~/src/emacs/src/emacs -Q -nw -L ~/src/notmuch/emacs/ --eval "(require >> 'notmuch)" -f notmuch -l /tmp/test.el >> >> wrongly show some other value for -f, depending on your EMAIL >> environment variable, for both compose-mail/message-send-and-exit >> and notmuch-mua-new-mail/notmuch-mua-send. >> (find-file "/tmp/sent") >> (insert "empty") >> (kill-region (point-min) (point-max)) >> (write-file "/tmp/sent") >> (kill-buffer) >> >> (find-file "/tmp/result") >> (kill-region (point-min) (point-max)) >> (write-file "/tmp/result") >> (kill-buffer) >> >> (find-file "/tmp/show-sendmail-args.sh") >> (kill-region (point-min) (point-max)) >> (insert "#!/bin/sh >> echo $* >> /tmp/result") >> (write-file "/tmp/show-sendmail-args.sh") >> (chmod "/tmp/show-sendmail-args.sh" 448) >> >> (setq sendmail-program "/tmp/show-sendmail-args.sh") >> (setq mail-specify-envelope-from t) >> (setq mail-envelope-from 'header) >> (setq send-mail-function 'sendmail-send-it) >> >> (compose-mail "Echo Mail Server " "test" >>'((From: . "exam...@example.org"))) > > This example, and the one below, are broken - you can't use “From:” > here, it has to be “From”. Changing that doesn't fix it, though. OK, thanks. >> (message-send-and-exit) >> >> (notmuch-mua-mail "Echo Mail Server " "test" >>'((From: . "exam...@example.org"))) >> (notmuch-mua-send-and-exit) >> >> (save-buffers-kill-terminal) > > As best I can determine, this relates to the order in which things are > loaded. > > If you load message.el before setting `mail-specify-envelope-from', > things are broken (sorry for the long lines): > > disaster-area ~/s/emacs % ./src/emacs -Q -nw -batch --eval "(progn (require > 'message) (setq mail-specify-envelope-from t mail-envelope-from 'header) > (message \"%s\" message-sendmail-envelope-from))" > nil > disaster-area ~/s/emacs % > > ...but if you load it after, things work fine: > > disaster-area ~/s/emacs % ./src/emacs -Q -nw -batch --eval "(progn (setq > mail-specify-envelope-from t mail-envelope-from 'header) (require 'message) > (message \"%s\" message-sendmail-envelope-from))" > header > disaster-area ~/s/emacs % > > This doesn't appear to be new behaviour - 26.1 does the same. this is astonishing, since my test script behaves different with emacs build with different last commits!? > This is
Re: [BUG] notmuch-emacs: spoils sendmail -f with emacs 27 commit 3a59cc84069376802ba8fd731b524d78db58262c and later
On Sunday, 2019-12-01 at 18:10:59 +01, Gregor Zattler wrote: > [@Stefan: FYI] > Dear notmuch developers, > > I use notmuch-emacs configured with > (setq mail-specify-envelope-from t) > (setq mail-envelope-from 'header) > (setq send-mail-function 'sendmail-send-it) > > this should/used to invoke sendmail (in my case exim4) with the email > address given in the From: header of the message buffer as > argument to sendmails -f option. Wow, this was, err, “interesting”. Comments below. > Since emacs 27 commit 3a59cc84069376802ba8fd731b524d78db58262c > > 3a59cc84069376802ba8fd731b524d78db58262c > Author: Stefan Monnier > AuthorDate: Tue Jul 30 16:37:01 2019 -0400 > Commit: Stefan Monnier > CommitDate: Tue Jul 30 16:37:01 2019 -0400 > > Parent: add146f09f * lisp/bindings.el > (mode-line-defining-kbd-macro): New defvar. > Contained: master > Follows:emacs-26.1 (6691) > > * lisp/gnus/message.el: Reduce redundancy with send-mail-function > > (message-send-mail-function) : Remove `local-library` tests > for libs distributed with Emacs. > (message-use-send-mail-function): New function. > (message-default-send-mail-function): Default to it, and remove cases > already handled by it. > (message--default-send-mail-function): New function. > (message-send-mail-function) : Use it as new default. > (message-sendmail-f-is-evil): Obey mail-specify-envelope-from if > available. > (message-check, message-with-reply-buffer): Use `declare`. > (message-smtpmail-send-it): smtpmail accepts mail-header-separator, > so simplify and declare obsolete. > (message-send-mail-with-mailclient): Declare obsolete. > (message-check-news-body-syntax): Don't presume that the checksum is > a fixnum. > > > this actually invokes sendmail -f with an address derived from the > EMAIL environment variable. > > > It took me some time to understand, that there is no problem with > compose-mail/message-send-and-exit which are bound to ^X m and ^C > ^C respectively within a barely configured emacs which I used for > testing. > If instead notmuch is loaded compose-mail/message-send-and-exit > and notmuch-mua-new-mail/notmuch-mua-send behave different. > > With this command (with test.el as attached): > > ~/src/emacs/src/emacs -Q -nw -l /tmp/test.el > > compose-mail/message-send-and-exit rightly show > -f exam...@example.org in the file /tmp/result (and then there is > an error because the notmuch commands are not known). > > While this command > > ~/src/emacs/src/emacs -Q -nw -L ~/src/notmuch/emacs/ --eval "(require > 'notmuch)" -f notmuch -l /tmp/test.el > > wrongly show some other value for -f, depending on your EMAIL > environment variable, for both compose-mail/message-send-and-exit > and notmuch-mua-new-mail/notmuch-mua-send. > > > I read the code but I have no idea why and how to debug this. > > Ciao; Gregor > -- > -... --- .-. . -.. ..--.. ...-.- > > (find-file "/tmp/sent") > (insert "empty") > (kill-region (point-min) (point-max)) > (write-file "/tmp/sent") > (kill-buffer) > > (find-file "/tmp/result") > (kill-region (point-min) (point-max)) > (write-file "/tmp/result") > (kill-buffer) > > (find-file "/tmp/show-sendmail-args.sh") > (kill-region (point-min) (point-max)) > (insert "#!/bin/sh > echo $* >> /tmp/result") > (write-file "/tmp/show-sendmail-args.sh") > (chmod "/tmp/show-sendmail-args.sh" 448) > > (setq sendmail-program "/tmp/show-sendmail-args.sh") > (setq mail-specify-envelope-from t) > (setq mail-envelope-from 'header) > (setq send-mail-function 'sendmail-send-it) > > (compose-mail "Echo Mail Server " "test" >'((From: . "exam...@example.org"))) This example, and the one below, are broken - you can't use “From:” here, it has to be “From”. Changing that doesn't fix it, though. > (message-send-and-exit) > > (notmuch-mua-mail "Echo Mail Server " "test" >'((From: . "exam...@example.org"))) > (notmuch-mua-send-and-exit) > > (save-buffers-kill-terminal) As best I can determine, this relates to the order in which things are loaded. If you load message.el before setting `mail-specify-envelope-from', things are broken (sorry for the long lines): disaster-area ~/s/emacs % ./src/emacs -Q -nw -batch --eval "(progn (require 'message) (setq mail-specify-envelope-from t mail-envelope-from 'header) (message \"%s\" message-sendmail-envelope-from))" nil disaster-area ~/s/emacs % ...but if you load it after, things work fine: disaster-area ~/s/emacs % ./src/emacs -Q -nw -batch --eval "(progn (setq mail-specify-envelope-from t mail-envelope-from 'header) (require 'message) (message \"%s\" message-sendmail-envelope-from))" header disaster-area ~/s/emacs % This doesn't appear to be new behaviour - 26.1 does the same. This is related to the way that `message-sendmail-envelope-from' is initialised from `mail-envelope-from', and it's `message-sendmail-envelope-from' that matters,
Re: [PATCH 4/5] tests: run python-cffi tests
David Bremner writes: > Tomi rightly observed that I somehow dropped the shutil.which change. As > penance, I created a seprate commit and pushed that to wip/cffi. > > d I have pushed this series to master. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 3/6] Move to dh 12
Daniel Kahn Gillmor writes: > Signed-off-by: Daniel Kahn Gillmor > --- > debian/compat | 1 - > debian/control | 2 +- > 2 files changed, 1 insertion(+), 2 deletions(-) > delete mode 100644 debian/compat This change introduces a large number of warnings from dh_missing. I guess this is because we install some things as upstream, and also in debian specific ways. I'd rather not introduce 75 lines of warnings into the build log at the moment. Do you want to rebase the series without this patch, or some solution? We can add the files to debian/not-installed, but that feels a bit ugly (and also technical debt, since that file will get out of date) d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: bind M-RET to notmuch-tree-from-search-thread
William Casarin writes: > This is an unbound function that is quite useful. It opens a selected > thread in notmuch-tree from the current search query. > > Signed-off-by: William Casarin merged to master. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: A prefix argument kills rather than browsing URLs
David Edmondson writes: > In `notmuch-show', the "B" key (notmuch-show-browse-urls) will kill > the URL if called with a prefix argument rather than browsing > directly. merged to master. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
