Introducing tmux-rs

tmux doesn’t really gain anything from memory safety because:

1. anything running in tmux already has execution rights and typically for the same user as tmux anyway.

2. Anyone who wanted to exploit tmux could just run ‘tmux -C’ and automatically get access to literally every interaction within tmux.

3. The software itself is already damn stable. I've never had it crash.

If you’re worried about someone exploiting your terminal then tmux is a terrible option, irrespective of whether it’s with written in C or Rust. And I say this as someone who absolutely loves tmux and uses it every day.

[edit]

And if you're worried about non-security related bugs affecting UX, then a rewrite in any language, regardless of the language, is a worse solution if your application has already been battle-tested for close to two decades. You're much better off creating something entirely new instead of porting code from one language to another because at least then you have new ideas instead of the same application but with new bugs in different places.

I don't say this because of some bias that Rust fanboys will assume I have. I love memory safe languages and think Rust is a great option for new projects. The point I'm making here is that a rewrite doesn't gain much for tmux SPECIFICALLY because tmux is already extremely stable.

There are reasons to be worried about additional safety beyond just security. My first thought when reading the article was it would be a huge bummer if a bug in tmux brought down a long-running or particularly stateful session. Of course, I’ve never encountered such a thing in my own usage, but if you could make it less likely that alone seems like a value add

Any program gains from memory safety. Memory safety is not just about security. It's about eliminating an entire class of bugs - buffer overflows, null pointer errors, use-after-free, the list goes on. They just so happen to be the kind of bugs that also tend to have serious security consequences.

I honestly don't get this relentless defense of 1970s-style programming. Do you think C is the pinnacle of programming language design? No? Then what's your point, exactly?

> Any program gains from memory safety. Memory safety is not just about security. It's about eliminating an entire class of bugs - buffer overflows, null pointer errors, use-after-free, the list goes on. They just so happen to be the kind of bugs that also tend to have serious security consequences.

Have you actually ever encountered such a bug in tmux though? Because I've been using it for around 15 years and can honestly say I haven't.

Yet this rewrite has introduced bugs. I know it's a hobby project so I'm not being critical. But if you're just trying to reduce bugs then rewriting code battle tested code in another language, regardless of that language, isn't the right way to go.

> I honestly don't get this relentless defense of 1970s-style programming. Do you think C is the pinnacle of programming language design? No? Then what's your point, exactly?

Where was I defending 1970s style programming? I wasn't even defending C. In fact the last project I've worked on based in either C or C++ was 10 years ago. Believe me, I'm a fan of memory safe languages ;)

My point was very clear and very specific to tmux. You're just trying to read between the lines and create a whole new argument where there was none.

If tmux was a new project then I'd agree with you. But, like yourself, I've using tmux for probably close to 15 years now and never had it crash once.

In fact the author of this project has admitted that they've introduced bugs with their rewrite. I know it's a hobby project so I'm not being critical of their work. But if we're only interested in reducing bugs then rewriting an existing project isn't the right way to go. Something like Zellij makes more sense because it's offering something new in addition to being written in Rust.

You forget that tmux is a terminal emulator. Trusted programs can have untrusted/attacker-controlled terminal output. If the program running inside tmux (e.g. cat, curl -s, weechat) can output malformed unicode or escape commands that trigger crashes or code execution, it is actually a huge problem.

> You forget that tmux is a terminal emulator.

No I don’t forget that.

> can output malformed unicode or escape commands that trigger crashes or code execution, it is actually a huge problem.

I agree.

And to go back to an earlier point, when was the last time you experienced tmux crash? Because I’ve been using it 15 years and yet to see that happen to me.

I get the need to protect against theoretical attacks, but what you’re advocating is throwing the baby out with the bathwater.

>Have you actually ever encountered such a bug in tmux though? Because I've been using it for around 15 years and can honestly say I haven't.

Since you asked, once every few months or so the whole server crashes which takes out all my windows. I don't know what exactly triggers it, other than it being something to do with pasting, and it's so infrequent that I haven't bothered to investigate it. Obviously the trivial repro of just pasting the same thing I tried to paste the first time doesn't repro it; I'd need to gdb the coredump, which is :effort:

I wouldn't expect this Rust rewrite or any other rewrite to fix it in any case; it would be more efficient to figure out the crash and fix it in the original C version.

I don't use tmux.

CVE-2020-27347 is exactly the kind of memory safety bug exploitable by terminal output that I was talking about.

I’m not going to deny that memory safety bugs are completely avoidable in C. However if the best example in tmux you can find is a bug that was patched promptly 5 years ago. That that’s does also say something favourable about tmux as well.

As I said elsewhere, if memory safety is a major concern then there are Rust multiplexers too. But there’s plenty more lower hanging fruit to worry about before tmux.

> it would be more efficient to figure out the crash and fix it in the original C version.

Jackpot.