> But otherwise, maybe better not rewrite working code....
Except that the eventual result allows for extension and improvements in a memory-safe language.
Except that the eventual result allows for extension and improvements in a memory-safe language.
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 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.
...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.
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.
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’ve already said there are other applications I do think benefit from a memory safe rewrite.
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.
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.
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.
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.
Not against untrusted URLs, no.
> You never cat or less a file you downloaded?
I don’t download untrusted files.
> You never ssh to servers run by other people?
100% no.
——-
Sounds like what you need more is a VM ;) executing anything untrusted in a secure environment is a dumb move.
Also dev time is massively shorter and the time I gain is spent on adding more features and tests.
Would recommend building low level projects in something like zig, if you care about build time and don’t want to use a dependency for everything.
Another comment in this thread hoped for "a brand new bulletproof tmux-resurrect". The reason there's a desire for such things is closely related to the limitations of non-trivial programs written in C.
They're harder to extend without bugs, harder for new team members to understand, and so on.
The "irrational obsession" has to do with advancing the state of the art beyond a primitive high-level assembler that was developed in the 1970s.
I find Rust fun and easy for writing system-level code, and I have enormous appreciation for the degree of correctness-by-construction that it can provide. Generally, if it builds, it works, as long as you're making proper use of the type system - make illegal states unrepresentable, as the saying goes. That's very difficult to do with C.
Rust isn't perfect. For most things, I'd rather be using Haskell, ML, or something on that level. But it's still on a completely different level from C, and rewriting the software ecosystem in it can only be an improvement.
Embed, designated initialization, and constexpr are really nice adds.
I maintain cargo-nextest, a widely-used test runner for Rust. It is possible to write nextest's runner loop in C, but it would be extraordinarily difficult — each test's state machine has dozens of states, there are several dynamic event sources as inputs, and the event loop relies heavily on epoll/kqueue/the equivalent Windows thing, as abstracted out by Tokio. So most test runners written in C don't even try to approach the quality, reliability, or portability of nextest.
It is possible to do this in C, because it compiles to machine code in the end. But would be out of reach for all but the most talented of C teams working over many years, and the portability costs would be massive. As a result, I don't know of a test runner that comes anywhere close to the feature set and portability of nextest that's written in C.
> I think you have no idea how big the C ecosystem is.
I'm definitely aware that the C ecosystem is much larger than the Rust ecosystem.
That's because the conditions created by C make solving this problem very hard, not because the problem isn't worth solving.
It is still a hard problem with Rust, requiring heavy use of async state machines to manage a rather extraordinary level of complexity. But at least it is possible for essentially a solo dev like myself to do in a robust, largely bug-free manner.
> I run my tests using "make" which somewhat poor but does the job.
Right, "make" is indeed not quite a high-performance enterprise-grade test runner with parallel test execution, high-quality reporting, signal handling, dynamic status querying, timeouts, retries, flaky test detection, mutual exclusion between tests, a DSL that lets you specify sets of tests, flexible configuration, archiving tests to run on another computer, sharding test runs, JUnit support, wrapper scripts, setup scripts, and several other features. Make doesn't even properly support Windows, which is table stakes for a portable test runner.
You're welcome to peruse the design documents:
https://nexte.st/docs/design/architecture/runner-loop/ (already linked above)
Rust is not portable at all compared with C code.
C definitely has a place, but "Rust is not portable at all compared with C code" is simply not correct. A lot more Rust code works across Windows and Unix than C code does. Rust's portability story is different from C's, much better in many ways but worse in others. In practice I do think Rust ends up being more portable than C in most practical scenarios -- for example, look at how things like `eza` work on Windows, the number one developer platform worldwide.
Statistically it is the most fun language there is, based on Stackoverflow. Portability is just a matter of time like with any language.
Abstraction happens on the level where tmux requirement is irrelevant. When the usage of Rust gets wider, people start adding support on compiler level for other needs. It is inevitable.
It was born in the 1970s and was standardized in the 80s and 90s. It continues to develop. Numerous data types have been added, along with unicode and threads. The C23 standard was released last year.
There comes a point at which it becomes necessary to move on.
All of these languages are Turing complete. So ultimately, if you're happy writing code in some language and don't want to change, that's your choice. But the reason Fortran or C or C++ isn't many people's first choice for new projects are closely related to the reasons I've mentioned. There will always be people who want to stick to what they know, but it's not only science that advances one funeral at a time.
And what makes you think today's "principled designs" won't get the boot a few years down the line too? These things are cyclical and rarely based on any real mathematical reasoning.
There are more factors to language use than design pattern fads. Like efficiency for example, which almost any modern garbage collected or managed language cannot meet beyond a certain level. And that usually gets worse the more "powerful abstractions" one adds. I want to learn FORTRAN because I have been told it has real benefits in terms of ergonomics for efficient code, ie normal looking FORTRAN code is faster than normal looking C/C++/Rust.
Efficiency is a real, concrete and measurable quantity. It is not subject to the fad of the day.
It's a different way of thinking about languages than most people usually do, but it's been true for FORTRAN since the 1950s and is true to some extent of every language with multiple implementations today.
C's lack of memory safety covers a broad range of concerns, including manual memory management, unrestricted pointers, null pointers (Tony Hoare's "billion dollar mistake"), buffer overflows, use-after-free, integer promotions, and so on.
Its weak type system is another fundamental limitation, closely related to its limited support for abstraction. The weakness of the standard library reflects this. The weak type system means that the static guarantees it provides are minimal. There were excuses for all this in 1975, there aren't any more.
Undefined behavior is more of an issue in C than in most languages. Again, not something you ideally want in a systems language.
Language-level concurrency support is virtually nonexistent.
Use of textual preprocessing, with limited semantic integration, as a language feature. Aside from the effects on the meaning of source code, it also makes building C programs more complex.
And again, the reason C23 hasn't addressed any of this significantly is because of fundamental limitations in the nature of the language. You can't "fix" these things without developing a new language.
This is an almost childish claim. If they're so easily avoided, how do you explain the enormously long list of CVEs for C and C++ programs?
> I do not think C++, Zig, or Go have a fundamental advantage.
We agree on that. They objectively do not. They're all an attempt to continue the C legacy. Go specifically is particularly ridiculous, having been designed quite recently by people from the 1970s who steadfastly refused to learn any lessons from the last 50 years of programming language development.
To be clear: I'm from the 1970s as well. I learned FORTRAN in 1977. But unlike the designers of Go, I didn't allow my understanding of programming language design to stagnate in the 1970s. I learned things. I studied things. I discovered things.
Do you believe that C is the ultimate in system programming language design? If you agree that it's not, then what are we arguing about exactly?
While I'd hardly disagree C and even C++ is lacking in memory safety compared to some newer languages, you are forgetting to normalize for sheer scale and userbase. If you have a Go project with the scale of popularity of Linux or Chrome or so on, then we can compare bug counts directly.
I don't follow; tmux-resurrect isn't written in C and is mostly useful to keep sessions across reboots.
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.
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.
CVE-2020-27347 is exactly the kind of memory safety bug exploitable by terminal output that I was talking about.
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.
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.
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?
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.
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.
Jackpot.