IPv2
commented
4 years ago The behaviour also depends on the end user's terminal emulator.
For example, using xterm, there is no issue - though this might not be a particularly interesting test, because xterm replaces the emojis with the Unicode U+FFFD Replacement Character.
In above reproduction steps, gnome-terminal shows the issue.
If Sup is run inside GNU Screen, then Sup can't display an email with a particular Subject header. Attempting to view the email in
thread-view-modeimmediately switches Sup intobuffer-list-mode, sounds a terminal bell, and Sup also acts as if the user has input "c" to start to compose an email, followed by typing some garbage for the "To" recipient.Possible security issue, since Sup acts as if it is receiving user input, but the origin is an email header?
Reproduce via a message with Subject containing "💜💙💚💛🧡":
Subject: =?utf-8?Q?=F0=9F=92=9C=F0=9F=92=99=F0=9F=92=9A=F0=9F=92=9B=F0=9F=A7=A1?=Complete example email in attached issue-572-demo.txt
The shortest problematic email Subject that I've found so far is "💜" (plays terminal bell when email opened, i.e., when switching to
thread-view-mode):Subject: =?utf-8?Q?=F0=9F=92=9C?=This isn't introduced by any recent commits - the same issue is also present in 0.22.1.
I haven't fully investigated yet, so I'm not sure at this stage whether this is a bug in Sup itself, or in an underlying library (e.g., ncurses), or even a bug or (mis-)feature of GNU Screen.
Reproduced when running Sup (version 0.22.1, 1.0, or 1.1-git-d3fbac13) inside GNU Screen (
screen) (4.06.02 or 4.08.00), running in the default configuration (i.e., no.screenrc).The issue does not occur when running Sup outside
screen, or if running Sup intmux.