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

41–50 of 395 posts

Re: Bugs Rust won't catch

#41

Post by JuniperMesos »

nine_k wrote: post #21
slopinthebag wrote: post #14

Earlier quoted context omitted.

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.

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 is it even possible to represent a negative PID, let alone treat the integer -1 as a PID meaning "all effective processes"? This seems like a mistake (if not a rookie mistake) in the Linux kernel API itself.

Re: Bugs Rust won't catch

#42

Post by throawayonthe »

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…

i don't think CVEs were a thing at the start of the GNU rewrite

Re: Bugs Rust won't catch

#43

Post by lelanthran »

irishcoffee wrote: post #12
AlotOfReading wrote: post #9

Earlier quoted context omitted.

Someone once coined a related term, "disassembler rage". It's the idea that every mistake looks amateur when examined closely enough. Comes from people sitting in a disassembler and raging the high level programmers who had the gall to e.g. use conditionals instead of a switch statement inside a function call a hundred frames deep. We're looking solely at the few things they got wrong, and not the thousands of correc…

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 find it hilarious that this comment is being downvoted.

Exactly what is the controversial take here?

> 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.

Nope. this is fine.

> Cloudflare crashed a chunk of the internet with a rust app a month or so ago, deploying a bad config file iirc.

Maybe this?

> Rust isn’t a panacea, it’s a programming language. It’s ok that it’s flawed, all languages are.

Nope, this is fine too.

Re: Bugs Rust won't catch

#44

Post by nineteen999 »

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...

Yeah perhaps learning UNIX API's and Rust at the same time doesn't lead to a drop in replacement ready to be shipped in major distributions. Who whould have thunk it.

Re: Bugs Rust won't catch

#45

Post by testdelacc1 »

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…

Is it possible you’ve misunderstood what Rust promises?

> It isn't possible to create a programing language that doesn't allow bugs to happen

Yes, that’s true. No one doubts this. Except you seem to think that Rust promises no bugs at all? I don’t know where you got this impression from, but it is incorrect.

Rust promises that certain kinds of bugs like use-after-free are much, much less likely. It eliminates some kinds of bugs, not all bugs altogether. It’s possible that you’ve read the claim on kinds of bugs, and misinterpreted it as all bugs.

I’ve had this conversation before, and it usually ends like https://www.smbc-comics.com/comic/aaaah

Re: Bugs Rust won't catch

#46

Post by pando85 »

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…

Memory safety catches buffer overflows. CI catches logic bugs. Neither catches the Unix API gotchas nobody documented.

Re: Bugs Rust won't catch

#47

Post by Dr_Emann »

cyberax wrote: post #34
collinfunk wrote: post #6

Hi, I am one of the maintainers of GNU Coreutils. Thanks for the article, it covers some interesting topics. In the little Rust that I have used, I have felt that it is far too easy to write TOCTOU races using std::fs. I hope the standard library gets an API similar to openat eventually. I just want to mention that I disagree with the section titled "Rule: Resolve Paths Before Comparing Them". Generally, it is better…

To be fair, Vec::set_len bug in Rust was in 2021. And even then it had to be annotated as `unsafe`. It was then deprecated and a linter check was added: https://github.com/rust-lang/rust-clippy/issues/7681

To be even fair-er, it wasn't actually memory unsafety, it was "just" unsoundness, there was a type, that IF you gave it an io reader implementation that was weird, that implementation could see uninit data, or expose uninit data elsewhere, but the only readers actually used were well behaved readers.

Re: Bugs Rust won't catch

#48

Post by Joker_vD »

oconnor663 wrote: post #39

> The trap is that get_user_by_name ends up loading shared libraries from the new root filesystem to resolve the username. That's kind of horrifying. Is there a reliable list somewhere of all the functions that do that? Is that list considered stable?

Nope! But basically, expect anything that resolves usernames, or host names, to be done in the userspace by NSS.

    Sun engineers Thomas Maslen and Sanjay Dani were the first to design and implement
    the Name Service Switch. They fulfilled Solaris requirements with the nsswitch.conf
    file specification and the implementation choice to load database access modules as
    dynamically loaded libraries, which Sun was also the first to introduce.

    Sun engineers' original design of the configuration file and runtime loading of name
    service back-end libraries has withstood the test of time as operating systems have
    evolved and new name services are introduced. Over the years, programmers ported the
    NSS configuration file with nearly identical implementations to many other operating
    systems including FreeBSD, NetBSD, Linux, HP-UX, IRIX and AIX.[citation needed] More
    than two decades after the NSS was invented, GNU libc implements it almost identically.
It's by design, you see.

Re: Bugs Rust won't catch

#49

Post by chiffaa »

Analemma_ wrote: post #7

I know nobody's perfect and I'm not asking for perfection, but these bugs are pretty alarming? It seems like these supposed coreutils replacements are being written by people who don't know anything about Unix, and also didn't even bother looking at the GNU tools they are trying to replace. Or at least didn't have any curiosity about why the GNU tools work the way they do. Otherwise they might've wondered about why t…

Few things to note

1. uutils as a project started back in 2013 as a way to learn Rust, by no means by knowledgeable developers or in a mature language

2. uutils didn't even have a consideration to become a replacement of GNU Coreutils until.... roughly 2021, I think? 2021 is when they started running compliance/compatibility tests, anyway

3. The choice of licensing (made in 2013) effectively forbids them from looking at the original source

Re: Bugs Rust won't catch

#50

Post by chiffaa »

Scarbutt wrote: post #5

[flagged]

Google people were specifically talking about memory safety. Logic bugs happen. All of the issues in TFA are effectively logic bugs or POSIX stuff, which is a different category entirely that Rust never claimed to solve
Post reply on HN