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 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.
The browser having a larger attack service is an argument for the browser being more important to run in a VM, not less.
Maybe you never expose your terminal to untrusted data, but that’s not the norm. Most people occasionally do things in their terminals like clone repositories and look at their READMEs, ssh to computers they don’t own, read email, even browse the web.
Note that I’m not arguing that tmux must be rewritten in rust for security. I’m saying that C code is virtually guaranteed to have vulnerabilities, and this is a major reason why people want to rewrite things in rust.
If you want to argue that tmux doesn’t have any vulnerabilities, I find that very unlikely, but you do you.
If you want to argue that rewriting tmux in rust isn’t worth the effort, you may be right, but you’re arguing against something I didn’t say.
This conversation is about the merits of rewriting in Rust due to memory safety.
My replies have been specifically about that those merits.
The only reason other arguments have been included is because people like to expand that scope. For example where you said (and I’m paraphrasing) that tmux isn’t free from bugs. Clearly I don’t believe that any software is 100% bug free. But that doesn’t mean that rewriting tmux in rust brings any pragmatic improvements to the table when weighed up against all the other options and concerns.
That might be what you’re talking about but it sure isn’t what I’m talking about and I never said a single word about the actual merits of rewriting vs keeping something in C.
I summarized my actual statements in the previous comment. You might infer (and quite reasonably so) a claim that a rust rewrite would be more secure. But any statement about the overall usefulness of such an endeavor is solely in your imagination.
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.