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

51–60 of 395 posts

Re: Bugs Rust won't catch

#51

Post by bpbp-mango »

aw1621107 wrote: post #33
nine_k wrote: post #21

Earlier quoted context omitted.

Yes, it's the lack of Unix experience that's terrifying. So many of mistakes listed are rookie mistakes, like not propagating the most severe errors, or the `kill -1` thing. Why were people who apparently did not have much experience using coreutils assigned to rewrite coreutils?

> Why were people who apparently did not have much experience using coreutils assigned to rewrite coreutils? From what I understand, "assigned" probably isn't the best way to put it. uutils started off back in 2013 as a way to learn Rust [0] way before the present kerfuffle. [0]: https://github.com/uutils/coreutils/tree/9653ed81a2fbf393f42...

exactly this. I wrote one of them back then as a learning experience. some of the code I wrote is still intact, incredibly.

Re: Bugs Rust won't catch

#52

Post by jeroenhd »

nine_k wrote: post #8
wahern wrote: post #2

> What’s notable is that all of these bugs landed in a production Rust codebase, written by people who knew what they were doing They knew how to write Rust, but clearly weren't sufficiently experienced with Unix APIs, semantics, and pitfalls. Most of those mistakes are exceedingly amateur from the perspective of long-time GNU coreutils (or BSD or Solaris base) developers, issues that were identified and largely hash…

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 programmers that don't use a Unix-like is vanishingly small.

This can also be a pain on microcontrollers sometimes, but there you're free to pretend you're on Unix if you want to.

Re: Bugs Rust won't catch

#53

Post by jeroenhd »

gmueckl wrote: post #31
irishcoffee wrote: post #12

Earlier quoted context omitted.

When I read the article I came away with the impression that shipping bugs this severe in a rewrite of utils used by hundreds of millions of people daily (hourly?) isn’t ok. I don’t think brushing the bad parts off with “most of the code was really good!” is a fair way to look at this. Cloudflare crashed a chunk of the internet with a rust app a month or so ago, deploying a bad config file iirc. Rust isn’t a panacea,…

I think that legitimate real world issues in rust code should be talked about more often. Right now the language enjoys a reputation that is essentiaöly misleading marketing. It isn't possible to create a programing language that doesn't allow bugs to happen (even with formal verification you can still prove correctness based on a wrong set of assumptions). This weird, kind of religious belief that rust leads to magi…

Nobody believes Rust programs are but free, though. Rust never promised that. It doesn't even promise memory safety, it only promises memory safety if you restrict yourself to safe APIs which simply isn't always possible.

Re: Bugs Rust won't catch

#54

Post by jeroenhd »

micheles wrote: post #17

> uutils now runs the upstream GNU coreutils test suite against itself in CI. That’s the right scale of defense for this class of bug. That's the minimum, it is absurd that they did not start from that!

I recall the last time there was a massive bug in the uutils project, it was because the coreutils tests didn't cover some crucial aspect people relied on. Running these tests is useful for compatibility and all, but it won't necessarily catch security issues.

Re: Bugs Rust won't catch

#55

Post by twhitmore »

slopinthebag wrote: post #14
wahern wrote: post #2

> What’s notable is that all of these bugs landed in a production Rust codebase, written by people who knew what they were doing They knew how to write Rust, but clearly weren't sufficiently experienced with Unix APIs, semantics, and pitfalls. Most of those mistakes are exceedingly amateur from the perspective of long-time GNU coreutils (or BSD or Solaris base) developers, issues that were identified and largely hash…

Seems pretty impressive they rewrote the coreutils in a new language, with so little Unix experience, and managed to do such a good job with very little bugs or vulns. I would have expected an order of magnitude more at least. Shows how good Rust is, that even inexperienced Unix devs can write stuff like this and make almost no mistakes.

[flagged]

Re: Bugs Rust won't catch

#56

Post by TheDong »

hombre_fatal wrote: post #23

One thing that's hard about rewriting code is that the original code was transformed incrementally over time in response to real world issues only found in production. The code gets silently encumbered with those lessons, and unless they are documented, there's a lot of hidden work that needs to be done before you actually reach parity. TFA is a good list of this exact sort of thing. Before you call people amateur fo…

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.

Re: Bugs Rust won't catch

#57

Post by swiftcoder »

rvz wrote: post #16

This is what happens when many people hype about a technology that solves a specific class of vulnerabilities, but it is not designed to prevent the others such as logic errors because of human / AI error. Granted, the uutils authors are well experienced in Rust, but it is not enough for a large-scale rewrite like this and you can't assume that it's "secure" because of memory safety. In this case, this post tells us…

> the uutils authors are well experienced in Rust

I'm not sure that they were all that experienced in Rust when most of this code was written. uutils has been a bit of a "good first rust issue" playground for a lot of its existence

Which makes it pretty unsurprising that the authors also weren't all that well versed in the details of low-level POSIX API

Re: Bugs Rust won't catch

#58

Post by timcobb »

The title of this article should be "Rust can't stop you from not giving a fuck" or "Rust can't give a fuck for you."

---

> What’s notable is that all of these bugs landed in a production Rust codebase, written by people who knew what they were doing

...

[List of bugs a diligent person would be mindful of, unix expert or not]

---

Only conclusion I can make is, unfortunately, the people writing these tools are not good software developers, certainly not sufficiently good for this line of work.

For comparison, I am neither a unix neckbeard nor a rust expert, but with the magic of LLMs I am using rust to write a music player. The amount of tokens I've sunk into watching for undesirable panics or dropped errors is pretty substantial. Why? Because I don't want my music player to suck! Simple as that. If you don't think about panics or errors, your software is going to be erratic, unpredictable and confusing.

Now, coreutils isn't my hobby music player, it's fundamental Internet infrastructure! I hate sounding like a Breitbart commenter but it is quite shocking to see the lack of basic thought going into writing what is meant to be critical infrastructure. Wow, honestly pathetic. Sorry to be so negative and for this word choice, but "shock" and "disappointment" are mild terms here for me.

Anyway, thanks for the author of this post! This is a red flag that should be distributed far and wide.

Re: Bugs Rust won't catch

#59

Post by misja111 »

The root cause of some of the bugs seems to be the opaque nature of some of the Unix API. E.g.

> The trap is that get_user_by_name ends up loading shared libraries from the new root filesystem to resolve the username. An attacker who can plant a file in the chroot gets to run code as uid 0.

To me such a get_user_by_name function is like a booby trap, an accident that is waiting to happen. You need to have user data, you have this get_user_by_name function, and then it goes and starts loading shared libraries. This smells like mixing of concerns to me. I'd say, either split getting the user data and loading any shared libraries in two separate functions, or somehow make it clear in the function name what it is doing.

Re: Bugs Rust won't catch

#60

Post by Galanwe »

jeroenhd wrote: post #53
gmueckl wrote: post #31

Earlier quoted context omitted.

I think that legitimate real world issues in rust code should be talked about more often. Right now the language enjoys a reputation that is essentiaöly misleading marketing. It isn't possible to create a programing language that doesn't allow bugs to happen (even with formal verification you can still prove correctness based on a wrong set of assumptions). This weird, kind of religious belief that rust leads to magi…

Nobody believes Rust programs are but free, though. Rust never promised that. It doesn't even promise memory safety, it only promises memory safety if you restrict yourself to safe APIs which simply isn't always possible.

> it only promises memory safety if you restrict yourself to safe APIs which simply isn't always possible.

Less than that actually, considering Rust has its own definition of what "safe" means.

Post reply on HN