From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Notmuch Mail <notmuch@notmuchmail.org>
Subject: BUG: emacs: fcc duplicates messages with variant bodies due to mml security
Date: Sun, 22 Oct 2017 19:28:12 -0400 [thread overview]
Message-ID: <87k1zm225v.fsf@fifthhorseman.net> (raw)
[-- Attachment #1: Type: text/plain, Size: 2077 bytes --]
I'm concerned that notmuch-emacs is causing variant messages of
encrypted/signed messages to be generated.
In particular, if notmuch-fcc-dirs is not nil, two variants of the
message bodies will be created: one will be sent through "notmuch
insert" and the other will be sent to sendmail.
the mml security modes (e.g. "#secure method=pgpmime mode=sign" (in
angle brackets)) take place after this bifurcation.
The result for a signed message is:
* the message sent to "notmuch insert" has one cryptographic signature
* the message sent to sendmail has a different cryptographic
signature, in particular if it is made more than 1 second later
(some signature algorithms will produce identical signatures if made
in the same second)
You can try this out by:
0) put ignore-cache-for-signing in ~/.gnupg/gpg-agent.conf
1) run "gpgconf --kill gpg-agent" to ensure the config is re-read
2) send yourself a signed message with message-id $mid.
3) Pull it back in however you receive mail, and then:
diff -u $(notmuch search --output=files "id:$mid")
If the messages were more than 1 second apart, you'll see the signature
part differs.
The result for an encrypted message is:
* the message sent to "notmuch insert" is encrypted with one session
key
* the message sent to sendmail is encrypted with a different session key
So the entire body of the message will be different.
I'm currently working around this by setting notmuch-fcc-dirs to nil,
and setting message-send-mail-hook to (dkg-notmuch-fcc), which is defined
as:
(defun dkg-notmuch-fcc ()
(shell-command-on-region (point-min) (point-max) "notmuch insert"))
this takes advantage of message-send-mail-hook's late-send. as the
documentation for that var says:
This hook is run very late -- just before the message is sent as
mail.
But this isn't something normal users should need to do manually.
Any emacs gurus want to propose a way to improve the situation? i'm at
a bit of a loss.
--dkg
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next reply other threads:[~2017-10-22 23:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-22 23:28 Daniel Kahn Gillmor [this message]
2022-01-19 13:56 ` BUG: emacs: fcc duplicates messages with variant bodies due to mml security David Bremner
2022-01-20 2:44 ` [PATCH] test/emacs: known broken test for matching fcc and sent message David Bremner
2022-01-20 3:02 ` David Bremner
2022-01-20 22:00 ` Tomi Ollila
2022-01-21 0:21 ` David Bremner
2022-01-21 11:37 ` David Bremner
2022-01-26 11:55 ` BUG: emacs: fcc duplicates messages with variant bodies due to mml security David Bremner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://notmuchmail.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k1zm225v.fsf@fifthhorseman.net \
--to=dkg@fifthhorseman.net \
--cc=notmuch@notmuchmail.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://yhetil.org/notmuch.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).