←back to thread

The Tor Project is switching to Rust

(itsfoss.com)
348 points giuliomagnifico | 2 comments | 12 Dec 25 12:35 UTC | HN request time: 0.532s | source
Show context
epolanski ◴[12 Dec 25 12:55 UTC] No.46243675[source]▶
If Rust helps with their pains and they like Rust this seems very sensible.

That's exactly why we have different languages and tools, because they adapt differently to different projects, teams and problems.

But as soon as you get into the silly "tool X is better period" arguments, then all the nuance of choosing the right tool for the job is lost.

replies(8): >>46243722 #>>46244465 #>>46244778 #>>46245023 #>>46245269 #>>46245325 #>>46246309 #>>46250138 #
dingdingdang ◴[12 Dec 25 13:02 UTC] No.46243722[source]▶
Sensible take, thank you. When HN get these "our project: from x to y language" frontpage stories I am always thinking that it would be far more exciting with "our project: 38.2% smaller code base by optimizing our dependency use", "our project: performance optimized by 16.4% by basic profiler use" or similar!
replies(4): >>46244428 #>>46244440 #>>46244501 #>>46244694 #
morkalork ◴[12 Dec 25 14:28 UTC] No.46244440[source]▶
Is the trade off here having more secure code in exchange for added complexity/difficulty? This is a real question, has the Tor code itself been exploited by bad actors before? All the incedences I've seen in the news were some other software running over tor that would be exploited to phone home or give up user data.
replies(1): >>46246041 #
uecker ◴[12 Dec 25 17:02 UTC] No.46246041[source]▶
It seems they worry about it, which I can understand. But now with Rust I worry about about new logic bugs, supply chain issues, and lack of proper security updates.
replies(1): >>46246797 #
steveklabnik ◴[12 Dec 25 18:07 UTC] No.46246797[source]▶
Well, given that this has been going on for years, you can already start to empirically evaluate that question.
replies(1): >>46246940 #
yjdiquhf ◴[12 Dec 25 18:18 UTC] No.46246940[source]▶
> (So far, it's a not-very-complete client. But watch this space!)
replies(1): >>46247052 #
steveklabnik ◴[12 Dec 25 18:27 UTC] No.46247052[source]▶
Yes, it's a beginning not the end.

Or, you could look at other projects who have been using Rust for many years, and consider these factors there too. The folks who have have generally concluded the opposite.

replies(3): >>46247083 #>>46248494 #>>46252883 #
uecker ◴[13 Dec 25 07:50 UTC] No.46252883[source]▶
The distribution I use already has limited security updates for Rust: https://www.debian.org/releases/trixie/release-notes/issues.... which reduces my security. The cargo supply chain issues are also very obvious, I am far more worried about this than I ever will be about memory safety, but hopefully tor reduces its reliance on random dependencies.
replies(1): >>46255297 #
steveklabnik ◴[13 Dec 25 15:38 UTC] No.46255297[source]▶
I find that surprising given that Debian breaks Rust programs up into individual apt packages, but ultimately, other distros do not have this issue. It’s also about userspace programs and not the kernel, which does not use external packages and so sidesteps this completely.

Debian forky has Rust in the kernel on by default.

replies(1): >>46255614 #
uecker ◴[13 Dec 25 16:15 UTC] No.46255614[source]▶
I guess the want to be able to update individual libraries to provide security updates.
replies(1): >>46256474 #
1. steveklabnik ◴[13 Dec 25 17:59 UTC] No.46256474[source]▶
Right, from my understanding, Debian was packaging Rust programs in the same way as C ones. So they’d update the individual library and it should be all good. They deduplicated all of the dependencies in their trees.
replies(1): >>46261775 #
2. uecker ◴[14 Dec 25 09:02 UTC] No.46261775[source]▶
This seems reasonable to me. If you have a tarmaggeedon, you update one library instead of thousand of packages. Although I am not sure how well this can work in Rust with monomorphization.