Introducing tmux-rs

I like this post, one can learn a lot.

It seems automatically translating Rust to C is not a very good idea: "I threw away all of the C2Rust output and decided I would translate all of the files into Rust manually from C.". Neither seems doing it manually: "I introduced many bugs while translating the code. I’d like to share the process of discovering and fixing a couple." Or using AI: "That’s because when using cursor to translate the code it would still occasionally insert bugs, just like me. So, I spent as much time reviewing the generated code as it would have taken me to write it myself."

As a hobby project, all power to you. But otherwise, maybe better not rewrite working code....

> But otherwise, maybe better not rewrite working code....

Except that the eventual result allows for extension and improvements in a memory-safe language.

There seems to be some rather irrational obsession about this.

It comes from the fact that nearly every useful program written in C has multiple security vulnerabilities just waiting to be found. In the unlikely event that you have a codebase that's free of them, you risk introducing one with any significant change.

Instead of just dogmatically asserting that any C program has security vulnerabilities, and changing C programs is also a security problem, you should look at what tmux's record actually is.

tmux has existed for approaching 18 years, and M. Marriott is still actively improving it as of last week. One can actually look at its record over that time, and, if that record is poor, replace proof by unsupported generalized assertion with proof based upon actual evidence.

* https://cvedetails.com/product/20683/Nicholas-Marriott-Tmux....

That search misses this: https://www.cvedetails.com/cve/CVE-2020-27347/

That is still quite a good record, but my statement stands. It is supported by decades of my experience working in C-derived languages. You don't have to accept my experience or believe my statement, of course, it's all the same to me.

That's a little like closing the barn door after the horse has already bolted because if you're concerned about security, then running any untrusted software in your terminal multiplexer is already a bad idea, regardless of whether your multiplexer is written in a memory-safe language or not.

...and before someone moans that I'm a C-fanboy, I'm really not. I've been writing software exclusively in memory-safe languages for 10+ years now. But I'm also pragmatic about when arguments about a RiR (rewrite-in-rust) are sensible and when they're not. In tmux's specific case, arguing about security misses the point.

You never run curl dumping to stdout? You never cat or less a file you downloaded? You never ssh to servers run by other people?

Seeming as I'm getting downvoted, let me explain my point better -- and please hear me through because I'm genuinely making some balanced arguments here rather than just viewing things as "black and white":

If you care about security enough to be concerned about memory-safety bugs in tmux, then tmux is already a fail, regardless of whether it's written in Rust. I detailed some features in another comment about some of tmux's features that basically make it spyware for untrusted code. And that's got nothing to do with the language it is written in.

But assuming you only care about terminal output and trust the software you execute, then you still have a hundred other libraries written in C between and tmux and the internet: openssh, libcurl, openssl, glibc, and so on and so forth. I'd actually welcome seeing many other those rewritten in Rust (or another memory safe language). So rewriting tmux before them is a lot like closing the barn door after the horse has already bolted.

Thus if you're genuinely concerned about memory safety security vulnerabilities then the only safe way to work with untrusted output is in a VM.

As it happens, this is exactly how highly secure systems operate. Their developers work on VMs which are tightly locked down by the vendor and easy to destroy if they become compromised.

Literally the only way to solve the problem you describe is to assume the entire stack is already compromised and thus run it in a sandbox.

So does rewriting tmux in Rust improve security? Yes, technically you're right. But it makes almost zero practical benefit compared to everything else. Memory-safety in tmux is not your weak link here. Not even remotely.

Disclaimer: I've developed terminal emulators, shells and terminal multiplexers in memory safe languages. My latest project makes heavy use of tmux integrations (again, in a memory safe language) so I'm very familiar with tmux's quirks. I also have a background in DevSecOps. You could almost say this topic is my specialist subject ;) The Rust hype is a generally good thing but misplaced in this very specific discussion.

Do you run your web browser in a VM and skip security updates for it since it doesn’t matter anyway?

I know you say you’re not viewing things in black and white, but “run in a VM or don’t care about security and vulnerabilities don’t matter” is exactly that.

I’m talking specifically about tmux.

I’ve already said there are other applications I do think benefit from a memory safe rewrite.

Why is it any different? All your arguments apply there as well.

Not really.

I don’t need to access untrusted sources from tmux. I do from Firefox.

Tmux has a smaller, easier to audit code base. Browsers are large, complicated and sprawling projects. That makes browsers a much larger attack surface.

Browsers already have sandboxing and other mitigations. Tmux doesn’t. Which means there are lower hanging fruit to fix in the terminal vs web browser.

Browsers are used by more people than tmux. So it’s a juicer target for zero-days.

We also already have Rust-based multiplexers for people who are worried about memory safety. There isn’t for web browsing.

Security is a scale of risk rather than something that is black and white. At some point the scales will tip and rewriting tmux in rust makes sense. But as said earlier, we already have Rust-based multiplexers for that eventuality. Whereas the need to harden browsers is much more urgent.

Context matters when it comes to InfoSec. At this point in time, rewriting tmux in Rust offers marginal gains vs rewriting a browser in Rust.