On 02Sep2015 11:31, mwnx <m...@gmx.com> wrote, with embedded ANSI escapes:
^[[33;1m[-- PGP output follows (current time: Wed Sep 2 11:15:01 2015) --]^[[0m
gpg: Signature made Wed Aug 19 22:17:44 2015 CEST using RSA key ID 0312C726
gpg: Good signature from "mwnx <m...@gmx.com>"
Primary key fingerprint: AEC9 554B 07BD F60D 75A3 AF6A 44E8 E4D4 0312 C726
^[[33;1m[-- End of PGP output --]^[[0m
[...]
As an illustrative example, the "_through_" above is displayed on my
terminal in cyan, _not_ underlined. [...]
This illustrates that the source ANSI sequence is not passed through. [...]
Well my concern is with the possibility of faking PGP related messages, as
mentioned in the manual:
Messages containing these codes are rare, but if this option is set,
their text will be colored accordingly. Note that this may override
your color choices, and even present a security problem, since a
message could include a line like
[-- PGP output follows ...
and give it the same color as your attachment color (see also
Oh, by the way, if you're using the default (I think it's default) bold
yellow coloring for GPG messages, you might not have noticed that this
message isn't actually GPG signed if you didn't bother to check the
timestamp. I know I don't usually bother to.
You're right, I had not noticed. Disturbing.
On this issue, I have commented out my "color" and "mono" directives for "bold"
and "underline", which at least gets me bold and underline ANSI sequences
transcribed as the terminal's bold and underline.
[ Aside: I discovered that I had to comment these out; I couldn't say "colour
underline underline default" - mutt rejects "underline" as a colour!
]
Still, I can see that allowing ANSI through conflicts with mutt's coloured
markup of boundaries (signatures, attachment markers etc).
What is a sensible approach here?
Cheers,
Cameron Simpson <c...@zip.com.au>
