On Thu, Apr 18, 2024 at 06:37:50PM +0200, Alejandro Colomar wrote: > Hi mutt(1) and neomutt(1) developers! > > I reported around a month ago a couple of security vulnerabilities to > neomutt(1), but which are also present in mutt(1) and every MUA > (probably, I didn't do an exhaustive research).
While I don't presume to speak for Kevin, or anyone with commit
access, here are my thoughts:
1. None of the issues you listed are security vulnerabilities. I'm
also fairly sure that anyone sophisticated enough to use Mutt AND
make regular use of encryption is not going to be confused by any
of the display-related issues you pointed out. If you are going to
use encryption, then it's incumbent upon you, the user, to
understand how it works, what it protects, and what it does not
protect. It's definitely an advanced use case.
a. If you don't want to expose the "real" subject--don't. You have
full control over what you put there. Likewise, you can also
write whatever you want in the body of the message to address
that.
b. There are valid reasons (e.g. Bcc) why the message may be
encrypted to someone not on (your copy of) the headers. By and
large, as the recipient, that's none of your business.
Presumably, the sender knows what's happening and that's what
matters.
c. Pretty much the same thing with a listed recipient to whom the
message is NOT encrypted.
d. The blank lines are for readability--a display-only concern--and
displaying them has no actual impact on security. If you have
reason to do something with the actual encrypted body other than
neatly displaying it for your reading pleasure, process the
actual message body outside Mutt in whatever manner you care to.
e. "Hidden" recipients: If you want to hide your recipients from
each other, just send a separate message. I haven't ever needed
to but presumably you can use Mutt's command line interface to
script this, so it's probably actually pretty trivial to do that
already.
f. "phishing protection" -- First, in the context of encrypted
messages, this doesn't seem like a legitimate concern. You're
going to know who your recipients are, and their keys, and this
won't be a factor. But recipients' (or senders') addresses
which are not 8-bit clean need to be encoded anyway, according
to RFC 6531, so just looking at the headers will already reveal
that.
g. Protecting the recipients is problematic for potentially several
reasons--it prevents people from interacting normally with
threads and their recipients. The SMTP envelope needs at least
the recipient you're actually sending to in that specific SMTP
session, and the MTA will add the recipient's address in a
Received header, so hiding that at least is pointless. But if
Mutt added these features it would be the only client to do so
(AFAIK) making it very difficult for anyone using any other
client to deal with. You couldn't simply "reply-all" to, well,
reply to all... And again, you can just send separate messages.
And if you really don't want your recipients to know about each
other, then you shouldn't be sending them the same message
anyway! Avoid any possibility of embarrassment or worse--send
separate messages.
h. The rest are just minor display issues--preferences--and have
nothing to do with security whatsoever AFAICT.
2. Many of these violate existing standards, or at least have no
standard. Standards exist for a reason--if you don't follow them,
other people who don't happen to use the exact same client as you
won't be able to interoperate.
3. Probably most importantly, Mutt is basically in maintenance mode,
i.e. no new features. So none of this is likely to get
implemented, even if one of the developers happened to agree with
you.
Personally, I would not be in support of the vast majority of what you
suggested. Maybe the "hidden recipient" for Bcc, but again, avoid the
whole problem and send a separate message. But the bulk of what
you're suggesting is a ton of work and extra complexity for really
very little or no genuine benefit, and potentially significant
interoperability problems.
--
Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address. Replying to it will result in
undeliverable mail due to spam prevention. Sorry for the inconvenience.
signature.asc
Description: PGP signature
