[unclejuan]

I think this is the breaking point where replacing our code written in C for code written in memory safe languages is becoming urgent.

The vast majority of vulnerabilities found recently are directly related to being written in memory unsafe languages, it's very difficult to justify that a DNS/DHCP server can't be written in rust or go and without using unsafe (well, maybe a few unsafe calls are still needed, but these will be a very small amount)...

[turpentine]

https://news.ycombinator.com/item?id=47943499 - 44 CVEs trying to replace coreutils with a greenfield rust rewrite. There's no free lunch.

[empath75]

They aren't the same kinds of problems, though.

[amiga386]

They really are, though. Security is all-encompassing, including not just programming languages, libraries, programs, but also systems, humans and their processes. Don't forget physical security either.

There are no silver bullets, and if the Rust Hype Squad told you there were and all you had to do was buy their product, they were just bamboozling you to push adoption of their pet language.

Write in whichever language you like. Including Rust. Including C. Even PHP. You can write secure software if you put your mind to it.

[empath75]

If you have a pick proof lock, that is better than an easily picked lock, even if someone can still kick your down down, or if you forget to lock it.

[amiga386]

That's not a great analogy. There are no pick-proof locks (...that are mechanically operated and admit keys; I'm presuming you didn't mean "pick-proof" in that there is no keyhole to pick but is defeated some other way, e.g. a keypad, you meant maximally pick-resistant in contrast to "easily picked")

And honestly? No! If someone can kick your door down, don't waste your money on a super-secure lock, they will just kick your door down. And if you're having your door kicked down on the regular, don't even focus on bolstering the door (they'll either start using power tools or take some other tact like smashing your windows or drilling through the floor or roof). Leave the door open if you like, but move whatever's attracting the attention of intruders somewhere more defensible. Focusing on the securing the wrong thing is also a security flaw!

[kjs3]

Ah...these security issues are perfectly cromulent because my shiny new magical beans language let's me screw up in brand new ways, not the old and busted boomer screwups. New is always awesome.

[Orygin]

How many CVEs in coreutils over the years? The project has the advantage of being old enough for them to be fixed. Call me when the rust rewrite has been there that long and still has more CVEs than the GNU counterpart.

[kokada]

Not sure how reliable this site is, but if it is correct it looks like 10: https://www.cvedetails.com/vulnerability-list/vendor_id-72/p....

Maybe coreutils is so old that most security vulnerabilities was solved before CVE even existed. But I think this is also a good argument why we are replacing a solid piece of C code to Rust just because it is "memory safe" and then have lots of CVEs related to things like TOCTOUs (that Rust will not save you).

[Orygin]

I'm not against rewriting it in Rust because I believe it really may help in certain class of bugs, but indeed it should not be replacing the old version instantly for that reason. Both could co exist, even tho you still need some guinea pigs to test it out and find issues.

Other than security, Rust brings major improvement to the tooling and may help bring fresh members that wouldn't want to contribute to C code. I understand why some projects go that route

[ajsnigrutin]

> Other than security, Rust brings major improvement to the tooling and may help bring fresh members that wouldn't want to contribute to C code. I understand why some projects go that route

But it loses old members who don't program in rust, already know the projects, all the reasons of why "this thing" was done "that way". and introduces a new set of bugs, plus now you have two versions of the same thing to maintain.

[bayindirh]

People thinking that using a superior tool (on paper) enables them to automatically write better tools than the ones who are battle tested over the years baffles me to no end.

Yes, you can go further, possibly faster. OTOH, nothing replaces experience and in-depth knowledge. GNU Coreutils embodies that knowledge and experience. uutils has none, and just tries to distill it with tests against the GNU one.

...and they get 44 CVEs as a result in their first test.

[hombre_fatal]

There was an article posted to HN recently that enumerated bugs in the rust rewrite.

Iirc the bugs had to do with linux system details like fs toctou and other things you'd only find out about in production.

Ideally we'd have a better way of navigating platform idiosyncrasies or better system APIs, so that every project doesn't have to relearn them at runtime. But the rewrite isn't pure downside.

[bayindirh]

I'm personally not against Rust rewrites in principle. But doing them in this drive-by hostile manner, esp. with non-GNU licenses smells "hostile takeover" for me, and dismantling core free software utilities is not nice in general.

> Ideally we'd have a better way of navigating platform idiosyncrasies or better system APIs

I believe trying to make something idiot-proof just generates better idiots, so I prefer having thinner abstractions on the lower level for maintenance, simplicity and performance reasons. The real solution is better documentation, but who values good documentation?

Graybeards and their apprentices, mostly from my experience. I personally still live with reference docs rather than AI prompts, and it serves me well.

[pdimitar]

My read on those was basically that the classic filesystems are hopelessly broken and we need ACID guarantees in the next-gen filesystems, like 20 years ago.

Not saying all of them were about FS TOCTOU bugs but once I got to these, that was my takeaway.

Obviously just using Rust cannot fix _all_ bugs, and I reject any criticisms towards Rust rewrites that tear down this particular straw man (its goal being to make it impossible to argue against). That's toxic and I get surprised every time people on HN try to argue in that childish way.

But if we can remove all C memory safety foot guns then that by itself is worth a lot already.

Losing decades-old knowledge on how the dysfunctional lower-level systems work would be regrettable and even near-fatal for any such projects. That I'd agree with. But it also raises the question on whether those lower-level systems don't need a very hard long look and -- eventually -- a replacement.

[overfeed]

I like rust as a language, but boy, the violent, zero-sum proselytising gets on my nerves. It's not enough for Rust to win, but C must be beaten to a pulp and its head mounted on a pike.

New projects wearing an another project's skin have always bothered me - regardless of language. Ubuntu did a similar thing way back with libav masquerading as ffmpeg.

[LtWorf]

But removing all the memory footguns while introducing hundreds of syscalls footguns where rust won't help you at all might not be better at all,

[account42]

> The project has the advantage of being old enough for them to be fixed.

That's exactly the point though - replacing established projects is inherently risky no matter how many safety buzzwords the replacement can cram into its GitHub tags.

[user3939382]

Maybe the problem is the way we think of dynamic memory. “Oh I don’t know what my maximum size for this is going to be, everything has to be dynamic” Is that really true? Is it really the end of the world for programs to declare maximum acceptable sizes for their inputs, and after that error out or use a ring buffer? If sizes were known you could design around that when using them. Your ram bank is finite, why is every layer inside of it then designed to pretend to be infinite? The rust thing strikes me as a massive waste of time and doesn’t solve the fundamental problem of modeling our programs correctly for reality which is finite system resources, and not just memory. c.f. Chrome loading 4 GB models onto people’s machines.

[ok123456]

This is exactly how people thought before 1995. Then everyone started "smashing the stack for fun and profit." In the end, you're trading one set of bugs (dynamic memory bugs and hard to reliably exploit) for another (overflow and easy to reliably exploit).

[megous]

Yeah, you still have to check for the limits, not just declare them. Then have fun smashing anything.

[account42]

> Is it really the end of the world for programs to declare maximum acceptable sizes for their inputs, and after that error out

It's supremely annoying when you run into arbitrary limits like that as a user. Often it's like a deliberate expiration date for the software as the world moves on to larger files/etc.

[Yokohiii]

The problem is the lack of talent that is willing to work on this, not the language.

AI Security researchers at least do something. If it was so easy to rewrite everything in rust, I don't know why the response to this incidents isn't a rock solid replacement in rust, the next day.

I tell you why that is. Working on these things doesn't give you stars on github.

[bluedragon1221]

That is a very pretentious opinion. Dnsmasq is a ubiquitous project, ~14 years old, and has maintainers that are very experienced in c and in the codebase. Telling them to rewrite in a language they are (maybe) unfamiliar with, even with the help of AI, will make these maintainers' experience worthless.

People seem to think that rewriting in rust just magically fixes all issues, but that's not how it works (See recent uutils CVEs). Rewrites tend to have more bugs because the code is new and hasn't been reviewed as much.

[bigiain]

I'm pretty sure we are getting close to the point where a few thousand bucks worth of tokens is enough for an agent coding session to reproduce a significant sized (but not linux kernel sized) C codebase in Rust that's 100% security bug for security bug compatible with the original. And _maybe_ "given enough eyeballs, all bugs are shallow" was true or even close top true once. But non of the "new code" ever has a _single_ eyeball cast over it. You know how sometimes you can stare into the code you wrote for weeks, but as soon as somebody else sees it they go "Hmmm, that bit looks odd. Are you sure it's right?" For most vibe coders or agents coders, it's all the same tool that generated the code that's looking for the bugs - it seems reasonable to assume that if a particular LLM generated the buggy code in the first place, it's at least as unlikely to find the bugs as a human who write buggy code?

[swiftcoder]

> I'm pretty sure we are getting close to the point where a few thousand bucks worth of tokens is enough for an agent coding session to reproduce a significant sized (but not linux kernel sized) C codebase in Rust

Given a comprehensive test suite for the original, probably, yes. if the test suite isn't great, you are still going to spend a lot of time/tokens chasing edge cases.

> that's 100% security bug for security bug compatible with the original

You can do this part without AI. c2rust will give you a translation that retains all the security bugs (and all the memory unsafety). The hope is that the AI in the loop will let you convert it to idiomatic rust (and hence avoid the memory unsafely, and in doing so, also resolve some of the security issues).

[Yokohiii]

I think I was ambiguous.

> If it was so easy to rewrite everything in rust, I don't know why the response to this incidents isn't a rock solid replacement in rust, the next day.

Meaning that AI/Rust enthusiasts are supposed to supply solutions. Of course they won't.

[LtWorf]

But they will produce a lot of posts on this website to say that it's only 3 weeks away.

[pdimitar]

> People seem to think that rewriting in rust just magically fixes all issues

Citations and links, please.

[Yokohiii]

I am not a journalist, nor your nanny.

[pdimitar]

Then you're claiming falsehoods supporting your prejudices. Good to know.

Though I wonder why.

[Rexxar]

> Citations and links, please.

"bigiain" comment, in the same discussion is an example: https://news.ycombinator.com/item?id=48120707

There is comment like this everywhere, if you don't see them it's just that you don't want to see them. There are a little less frequent than 5 years ago but still frequent enough in each c, c++ or rust discussions.

[pdimitar]

Which part of the comment comes off as fanatic to you?

I'd disagree with that poster that you can write 100% security bug free code just like that.

> There is comment like this everywhere, if you don't see them it's just that you don't want to see them.

Can you discuss productively without attacks? Mine was, and still is, a question of genuine curiosity. And the only "fanatic" thing in your linked comment is a bogus 100% claim. I'm not seeing fanaticism.

[Rexxar]

> Which part of the comment comes off as fanatic to you?

I didn't use the word 'fanatic' neither the previous comment you were responded too.

> Can you discuss productively without attacks?

So you thing someone telling you "look a little harder" is a "personal attack" ? After I took some time to give you a link you ask for ?

> I'm not seeing fanaticism.

You are the only one using this word in this discussion.

[LtWorf]

> I don't know why the response to this incidents isn't a rock solid replacement in rust, the next day.

Go ahead and ask your AI to make it. What's stopping you?

[krferriter]

> What's stopping you?

Based on their comment I guess they are worried they won't earn enough stars on github

[LtWorf]

They can simply buy them :D

At a talk to showcase how dumb stars/downloads are to measure popularity I showcased a tool to reach the most downloaded list very easily.

The owners of code repositories that release download counts stats without even aggregating them by IP address are fully aware of it.

Probably some people play the stats to seem popular and get VC funding.

[x3n0ph3n3]

I disagree -- we're clearly getting better safeguards by way of AI agents to spot potential vulnerabilities!

[jabl]

The question is whether the current situation is a short burst of action, and once those most critical bugs get fixed the hype around AI vulnerability scanning will die down, or whether the current crop of system/infra software written in vulnerable languages like C are beyond redemption and they will provide an endless source of critical bugs for AI to find until we fix them by rewriting them in Rust/Go/whatever.

[yardstick]

An eternal summer of CVEs is upon us

[KronisLV]

Seems like those “rewrite in Rust” folks had a point after all (the viability of it for any number of projects being another thing entirely).

[LtWorf]

https://www.securityweek.com/tanstack-mistral-ai-uipath-hit-...

[Terr_]

A better use of LLMs: To help translate the vast majority of C/C++ developers' output into memory-safe languages. :p

[lionkor]

You're likely joking, but in case someone else misunderstands; this is not going to work. Rust with unsafe{} is the only thing you can translate directly to, even with LLMs. Rust with extensive unsafe{} is not something anyone wants to debug or maintain, and is near impossible to improve quickly.