On Thu, Apr 28, 2016 at 06:49:58PM +0200, Ingo Schwarze wrote: > Hi Nic, > > Nicholas Marriott wrote on Thu, Apr 28, 2016 at 01:11:44PM +0100: > > > tmux is not some sort of terminal firewall. Of course we try to avoid > > anything obviously stupid, but we also want stuff that works outside > > tmux to also work inside. > [...] > > Assuming a width of 1 where we can't get a width from the system > > is not a big step and I do not think it poses any more of a > > security risk than just running the application without tmux. > > Oh. That does look like a valid argument that i missed. > > Note, though, that most terminals display nothing at all when being > fed a non-printable character (except that, of course, there are
If this was just guaranteed nonprintable characters, there would be no issue. But the problem is that some platforms are missing genuine UTF-8 characters and since many terminals do not use wcwidth(), it means that users who used older versions of tmux had working characters that now do not work even though the terminal is happy to show them. I think if nonprintable characters show up, it will be because a user printed garbage and they will know they printed garbage and not expect sensible output. However I think you are right and there is no reason for this to be in OpenBSD, I'll move it into portable tmux only. Since it is only a couple of lines it is not a big issue. > various control characters that change terminal state and can have > extensive effects on how subsequent text will be printed). So i'm > not quite convinced the value 1 is better than the value 0. Then > again, i don't worry that much which value you use, i mostly worried > about treating non-printables as printable at all. I don't think it is tmux's role to protect the terminal and there is no way it can do it. Sometimes we just have to assume that the terminal will behave sensibly. > > > tmux is /not/ getting the width with wcwidth() for some sort of > > protective sanity check, it is getting it so it can keep its own state > > correct. If we can't get the width, using the best guess of what the > > terminal outside will do is fair and will fix more problems than it > > causes. > > In that case, it might make sense to add a comment explaining that > non-printable characters are intentionally passed through, because > doing so is no more dangerous than not using tmux(1) in the first > place. > > Given that failing to check the wcwidth(3) return value against -1, > or mishandling that case in some way, is a very common and usually > dangerous error, such a comment can help to avoid serious confusion > of code auditors, like the one you witnessed on my part. Saying > "hope for the best", as you do now, rings all the alarms instead. > > Yours, > Ingo
