Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bugs Rust won't catch

corrode.dev

Post reply on HN
Print view View original

141–150 of 395 posts

Re: Bugs Rust won't catch

#141

Post by geocar »

Joker_vD wrote: post #99
geocar wrote: post #84

Earlier quoted context omitted.

> The root cause of some of the bugs seems to be the opaque nature of some of the Unix API. Seems and smells is weasel words. The root cause is not thinking: Why is root chrooting into a directory they do not control? Whatever you chroot into is under control of whoever made that chroot, and if you cannot understand this you have no business using chroot() > To me such a get_user_by_name function is like a booby trap…

> The root cause is not thinking: Why is root chrooting into a directory they do not control? Because you can't call chroot(2) unless you're root. And "control a directory" is weasel words; root technically controls everything in one sense of the word. It can also gain full control (in a slightly different sense of the word) over a directory: kill every single process that's owned by the owner of that directory, then…

> And "control a directory" is weasel words;

I did not choose the term to confuse you, that's from the definition document linked to the CVE:

https://cwe.mitre.org/data/definitions/426.html

The CVE itself uses the language "If the NEWROOT is writable by an attacker" which could refer to a shared library (as indicated in the report), or even a passwd file as would have been true since the origin of chroot()

> root technically controls everything in one sense of the word.

But not the sense we're talking about.

> Because you can't call chroot(2) unless you're root

Well you can[1], but this is /usr/sbin/chroot aka chroot(8) when used with a non-numeric --userspec, and the point is to drop root to a user that root controls with setuid(2). Something needs to map user names to the numeric userids that setuid(2) uses, and that something is typically the NSS database.

Now: Which database should be used to map a username to a userid?

- The one from before the chroot(2)?

- Or the one that you're chroot(2)ing into

If you're the author of the code in-question, you chose the latter, and that is totally obvious to anyone who can read because that's the order the code appears in, but it's also obvious that only the first one* is under control of root, and so only the first one could be correct.

[1]: if you're curious: unshare(CLONE_USERNS|CLONE_FS) can be used. this is part of how rootless containers work.

Re: Bugs Rust won't catch

#142

Post by hu3 »

tnova wrote: post #110
hu3 wrote: post #86

Earlier quoted context omitted.

For core system functionality maybe. But for most applications Rust slow compiler iteration speed becomes a bottleneck when the likes of TypeScript (with Bun) and Go have sub second iteration times. Plus AI is also good at catching, in other languages, errors that Rust tooling enforces. Like race conditions, use after free, buffer overflows, lifetimes, etc. So maybe AI will become to ultimate "rust checker" for any l…

In my experience developing different types of applications in Rust, the claims of a "slow compiler" are overstated. Sub second iteration times are definitely a thing in Rust as well, unless you're adding a new dependency for the first time or building fresh.

Our experiences clearly differ then. And for others as well since it's a common complain.

Countless time I have seen other people complain as well. There are articles about it even. Can't find the YouTube link now but recently a gamedev abandoned Rust due to compilation speed alone because iteration speed was paramount to their creative process.

Handwaving isn't going to make it any better. And thinking Go/TS compilation speed are comparable to Rust is, a handwave and a half to say the least.

Cargo check and friends are subpar for AI because they actually need to run the thing and unit tests for efficient agentic loops.

A single loop might recompile and rerun the application/unit tests enough times that slow compilers like Rust and Scala become detrimental.

Re: Bugs Rust won't catch

#143

Post by snovv_crash »

dbdr wrote: post #75
TheDong wrote: post #56

Earlier quoted context omitted.

What's even harder is doing that while trying to avoid the GPL, so doing that without reading the original source code. uutils would be so much better imo if it was GPL and took direct inspiration from the coreutils source code.

The GPL prevents you from reading the licensed code before writing related non-GPL code? Which section of the GPL says that?

This is clean room implementation 101, and why LLMs are so controversial in terms of licensing.

Re: Bugs Rust won't catch

#144

Post by nh2 »

kibwen wrote: post #125
juergbi wrote: post #107

Earlier quoted context omitted.

> So I agree that Rust's stdilb is somewhat mistake prone; not so much because it's being opinionated and "nudg[ing] the developer towards using neat APIs", but because it's so low-level that it's not offering much "safety" in filesystem access over raw syscalls beyond ensuring that you didn't write a buffer overflow. `openat()` and the other `*at()` syscalls are also raw syscalls, which Rust's stdlib chose not to ex…

They're not missing, Rust just ships them (including openat) as part of the first-party libc crate rather than exposing them directly from libstd. You'll find all the other libc syscalls there as well: https://docs.rs/libc/0.2.186/libc/ . I agree that Rust's stdlib could use some higher-level helper functions to help head off TOCTOU, but it's not as simple as just exposing `openat`, which, in addition to being platfo…

But those are all unsafe, taking raw strings.

Why can I easily use "*at" functions from Python's stdlib, but not Rust's?

They are much safer against path traversal and symlink attacks.

Working safely with files should not require *const c_char.

This should be fixed .

Re: Bugs Rust won't catch

#145

Post by adrian_b »

flohofwoe wrote: post #79
slopinthebag wrote: post #18

I find it interesting how people will criticise Rust for not preventing all bugs, when the alternative languages don't prevent those same bugs nor the bugs rust does catch . If you're comparing Rust to a perfect language that doesn't exist, you should probably also compare your alternative to that perfect language as well right? I'd be interested in a comparison with the amount of bugs and CVE's in GNU coreutils at t…

What's the point of a "rewrite in Rust" when it introduces bugs that either never existed in the original or were fixed already? > I'd be interested in a comparison with the amount of bugs and CVE's in GNU coreutils at the start of its lifetime The point is, those bugs had been discovered and fixed decades ago. Do you want to wait decades for coreutils_rs to reach the same robustness? Why do a rewrite when the altern…

The Rust developers have not read the original coreutils, because they want to replace the GPL license, so they want to be able to say that their code is not derived from the original coreutils.

For a project of this kind, this seems a rather stupid choice and it is enough to make hard to trust the rewritten tools.

Even supposing that replacing the GPL license were an acceptable goal, that would make sense only for a library, not for executable applications. For executable applications it makes sense to not want GPL only when you want to extract parts of them and insert them into other programs.

Re: Bugs Rust won't catch

#146

Post by bonzini »

jeroenhd wrote: post #52
nine_k wrote: post #8

Earlier quoted context omitted.

More than that: it seems that Rust stdlib nudges the developer towards using neat APIs at an incorrect level of abstraction, like path-based instead of handle-based file operations. I hope I'm wrong.

If anything, I find the rust standard library to default to Unix too much for a generic programming language. You need to think very Unixy if you want to program Rust on Windows, unless you're directly importing the Windows crate and foregoing the Rust standard library. If you're writing COBOL style mainframe programs, things become even more forced, though I doubt the overlap between Rust programmers and mainframe p…

That's the same for the C or Python standard libraries. The difference is that in C you tend to use the Win32 functions more because they're easily reached for; but Python and Rust are both just as Unixy.

Re: Bugs Rust won't catch

#147

Post by WJW »

awesome_dude wrote: post #114
dapperdrake wrote: post #26

Earlier quoted context omitted.

First of all, thank you for presenting a succinct take on this viewpoint from the other side of the fence from where I am at. So how can I learn from this? (Asking very aggressively, especially for Internet writing, to make the contrast unmistakable. And contrast helps with perceiving differences and mistakes.) (You also don’t owe me any of your time or mental bandwidth, whatsoever.) So here goes: Question 1: How com…

> Question 2: > Does throughput really matter more than latency in everyday application? IME as a user, hell yes Getting a video I don't mind if it buffers a moment, but once it starts I need all of that data moving to my player as quickly as possible OTOH if there's no wait, but the data is restricted (the amount coming to my player is less than the player needs to fully render the images), the video is "unwatchable…

I don't mean to nitpick, but absolute values for both of these matter much less than how much it is compared to "enough". As long as the throughput is enough to prevent the video from stuttering, it doesn't matter if the data is moved to your video player program at 1 GB/s or 1 TB/s. Conversely, you say you don't mind if a video buffers for a moment but I'm willing to bet there's some value of "a moment" where it becomes "too long". Nobody is willing to wait an hour buffering before their video starts.

The perception of speed in using a computer is almost entirely latency driven these days. Compare using `rg` or `git` vs loading up your banking website.

Re: Bugs Rust won't catch

#148

Post by bonzini »

adrian_b wrote: post #130
dbdr wrote: post #71

Earlier quoted context omitted.

I didn't downvote, but I feel the last two points show a lack of nuance. It's saying "Rust doesn't prevent 100% of the bugs, like all other programming languages", while failing to acknowledge that if a programming language prevents entire classes of bugs, it's a very significant improvement.

Nobody disputes that Rust is one of the programming languages that prevent several classes of frequent bugs, which is a valuable feature when compared with C/C++, even if that is a very low bar. What many do not accept among the claims of the Rust fans is that rewriting a mature and very big codebase from another language into Rust is likely to reduce the number of bugs of that codebase. For some buggier codebases, a…

It's not a low bar when C/C++/D are basically the only languages in which you can write certain kinds of programs.

Re: Bugs Rust won't catch

#150

Post by i_think_so »

TheDong wrote: post #85
dbdr wrote: post #75

Earlier quoted context omitted.

The GPL prevents you from reading the licensed code before writing related non-GPL code? Which section of the GPL says that?

It's based on an interpretation of "derived from". It does not matter if it's in the GPL explicitly or not since we're talking about uutils and their stance on it, and they've written that: https://github.com/uutils/coreutils/blob/6b8a5a15b4f077f8609... > we cannot accept any changes based on the GNU source code [..]. It is however possible to look at other implementations under a BSD or MIT license like Apple's impl…

"clearly implies"

Hmmmm....

Post reply on HN