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

281–290 of 395 posts

Re: Bugs Rust won't catch

#281

Post by Arch-TK »

pando85 wrote: post #46
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.

They're not API gotchas in most cases.

And writing comprehensive tests for this behaviour is very difficult regardless of which language you are using.

I am all for rust rewrites of things. But in this case, these are mistakes which were encouraged by the lazy design of `std::fs` and the developers' lack of relevant experience.

And to clarify, I don't blame the developers for lacking the relevant experience. Working on such a project is precisely the right place to learn stuff like this.

I think it's an absurdly dumb move by Canonical to take this project and beta-test it on normal users' machines though…

Re: Bugs Rust won't catch

#282

Post by ok123456 »

Avamander wrote: post #215
PunchyHamster wrote: post #171

Earlier quoted context omitted.

>Canonical's usage of uutils is likely for marketing Currently their usage is actively worsening the security of their distro

These things were caught and basically all of them weren't covered by any test suite (not even GNU coreutils'). It's a bit bold to claim that it's actively worsening it when it's not an LTS.

That's generally what you call introducing new semantic bugs.

Re: Bugs Rust won't catch

#283

Post by dvhh »

riffraff wrote: post #216
tambre wrote: post #167

Earlier quoted context omitted.

Worth noting is that in Debian experimental coreutils defaults to coreutils-from-uutils [0]. This came as a big surprise and as far as I can tell there's been no discussion. A Canonical developer seems to have unilaterally overwritten the coreutils package without discussing with the maintainer. All the package renames that are in Ubuntu aren't in Debian so you can't switch to GNU utils either without deep trickery i…

that... seems newsworthy on its own merit.

Considering how Ubuntu seems to influence Debian development, this is only slightly surprising.

See: https://lists.debian.org/deity/2025/10/msg00071.html - Hard Rust requirements from May onward - by a Core Ubuntu Developer

Re: Bugs Rust won't catch

#284

Post by geocar »

foobar1274278 wrote: post #221
geocar wrote: post #202

Earlier quoted context omitted.

100% it's the safer option. The software with the best security track record of all time is written in C.

I'm curious which software you have in mind. Ex: seL4 is technically C, but I'd say the theorem prover is doing most of the real work there.

Specifically? I'm thinking of qmail.

qmail was at one point the second most widely deployed email server, handling the majority of online mail. It wasn't a research project; it's not obscure. Yahoo used to use it.

And what I mean by track record: After more than a decade after the last published version, a theoretical attack was found requiring special setup uncommon for a sysadmin, and impossible ten years prior.

When anyone thinks about how to build reliable secure software, I think they should be thinking of qmail because it really has no public source-available equal, except maybe djbdns.

seL4 on the other hand makes some specious claims about some ten year old version of itself, and so few people have even heard about it you thought it important to remind it is "technically" C -- qmail isn't like that at all: There is no prover, no test suite, and almost no metaprogramming of any kind. It's just C.

Re: Bugs Rust won't catch

#285

Post by pxc »

theandrewbailey wrote: post #159
zx8080 wrote: post #136

Earlier quoted context omitted.

Agree with the point. Asking sincerely, how to filter out installing any rust-rewrite packages on my machines? Does anyone know the way?

I'm unaware of any Rust rewrites outside of coreutils, so: sudo apt install coreutils-from-gnu https://computingforgeeks.com/ubuntu-2604-rust-coreutils-gui...

There aren't true 1:1 clones, but there's ripgrep (inspired by GNU grep) and fd (inspired by GNU find). Those two I like, though. I think they're thoughtfully designed and in ripgrep's case at least (I just haven't read posts/comments by fd's author), it was developed with some close study of other grep implementations. I still use GNU grep and GNU find as well, but rg and fd are often nice for me.

Re: Bugs Rust won't catch

#286

Post by gmueckl »

testdelacc1 wrote: post #45
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…

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 ki…

I understand the (narrow) hard guarantees that rust gives. But there there are people in the wider community who think that the guarantees are much, much broader. This is a pretty widespread misconception that should get be rectified.

Re: Bugs Rust won't catch

#287

Post by bluGill »

aragilar wrote: post #219
bluGill wrote: post #180

I have to partially disagree with applying Hyrum's law here. In the case of core utils, there's not just the common GNU version. There's also what POSIX says they should do and what the various BSD does, plus some other implementations from various vendors that we mostly forget about. If in any case what this version of Core Utils does is different from what GNU does in a way that others are also different, it would…

But if you seek to replace coreutils (as at least is the case with Canonical it seems), rather than just be another POSIX userland implementation (e.g. busybox), then I would suggest you do need to be bug-compatible? I can apt/dnf/apk install busybox and use that for my user rather than coreutils, but given a significant amount of Linux infrastructure (including likely many personal scripts) are tied to coreutils, th…

As someone who prefers BSD I would make it my goal to become something reasonably popular on linux that isn't different just to force less reliance of the GNUisms in their core utils. Nothing wrong with the GNUisms on the command line, but there are are a lot of GNU assumptions in scripts that should be portable.

Re: Bugs Rust won't catch

#288

Post by Arch-TK »

jsdfasds wrote: post #181
Joker_vD wrote: post #48

Earlier quoted context omitted.

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 fir…

This is precisely why I don't link with glibc anymore.

musl has its own approach to this, it's called nscd

It would have avoided the "running code as root" part, but it would still allow an attacker to control the result of the function call.

I mean, the problem being solved here isn't exactly a bad problem to try to solve. You either permanently hard-code `/etc/passwd` as the user database, and `/etc/resolv.conf` as the source of DNS server information, or you allow these to be handled in a more complex way (thus allowing YellowPages, LDAP, or whatever you can imagine).

Re: Bugs Rust won't catch

#289

Post by Arch-TK »

stackedinserter wrote: post #185

TIL that > uutils read it as “send the default signal to PID -1”, which on Linux means every process you can see. What's the use case for killing all process you can see?

Many cases, including as a last resort as part of shutdown, to try to trigger remaining services into a graceful exit (although these days cgroups help avoid ever being in such a situation).

Re: Bugs Rust won't catch

#290

Post by dvhh »

geocar wrote: post #202
sgt wrote: post #190

Earlier quoted context omitted.

"The alternative languages" - in this case you're talking about C, 99% of the time. So let's talk about that. Well written C code, especially for the purpose of writing and continuing to maintain mature GNU coreutils, is not a big risk in terms of CVE. Between having an inexperienced Rust developer and an extremely experienced C developer (who's been through all the motions), I'd say the latter is likely the safer op…

100% it's the safer option. The software with the best security track record of all time is written in C.

I would recognize sarcasm when I see it. But statistically, that could be true, considering the amount of C code running ( probably far less than COBOL or FORTRAN ), Compared to the relatively small amount of Rust code vs the amount of faults observed with it.
Post reply on HN