←back to thread

Introducing tmux-rs

(richardscollin.github.io)
857 points Jtsummers | 1 comments | | HN request time: 0s | source
Show context
uecker ◴[] No.44456333[source]
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....

replies(4): >>44456413 #>>44456755 #>>44459370 #>>44459965 #
antonvs ◴[] No.44456755[source]
> But otherwise, maybe better not rewrite working code....

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

replies(2): >>44456866 #>>44458838 #
uecker ◴[] No.44456866[source]
There seems to be some rather irrational obsession about this.
replies(2): >>44456899 #>>44457353 #
wat10000 ◴[] No.44457353[source]
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.
replies(2): >>44458107 #>>44458499 #
JdeBP ◴[] No.44458107[source]
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....

replies(1): >>44458909 #
wat10000 ◴[] No.44458909[source]
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.

replies(1): >>44459411 #
hnlmorg ◴[] No.44459411[source]
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.

replies(1): >>44459854 #
wat10000 ◴[] No.44459854[source]
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?
replies(2): >>44461470 #>>44462258 #
1. hnlmorg ◴[] No.44461470{3}[source]
> You never run curl dumping to stdout?

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.