The coreutils Rust rewrite story : programming

[–] spectrums_coherence@piefed.social 4 points 1 week ago (1 children)

I am not happy about the license change for the rewrite. Theoretically, affine type system can be used to reason about deadlock and race conditions (although with caveats https://dl.acm.org/doi/abs/10.1145/3571229).

That being said, race conditions are logical bugs, and a programming language is only as powerful as the specification provided to it. It is possible there are condition that developers are simply not aware of.

It seems like specifying the race behavior of coreutil in an language agnostic way would be a fruitful endeavor.

[–] Snarwin@fedia.io 3 points 1 week ago

The real underlying issue here is that the OS interfaces these programs rely on are extremely error-prone and difficult to use correctly. A naive implementation of these system utilities in any language is basically guaranteed to stumble into bugs and vulnerabilities like the ones described in the linked message.

[–] NostraDavid@programming.dev 3 points 1 week ago* (last edited 1 week ago) (1 children)

Canonical should have a look at https://antithesis.com/ - They'll basically run your application in a deterministic VM, where hardware errors are simulated, so you can re-play certain scenarios, not just the happy-path. It should be able to surface bugs way faster than just running into them.

Deterministic simulation testing is what they should be doing.

edit: If you want a demo from the CEO, where he shows off how he tested Super Mario (yes, the NES game): https://www.youtube.com/watch?v=zc4cqtibTzs

Note: These are some guys from FoundationDB, if that means something to you.

[–] FizzyOrange@programming.dev 1 points 1 week ago

Tbh while DST (or just "testing" as hardware people would call it) is very obviously a great idea, I'm not sure it would have helped here - in order to detect these TOCTOU bugs you would need stimulus that triggers it and some kind of checker/model that has the correct behaviour.

That's totally possible but it's pretty hardcore testing for a software project and it's difficult to imagine doing that without realising that you have a TOCTOU issue just by inspection.

[+] onlinepersona@programming.dev -6 points 1 week ago (2 children)

C is a shit language, Rust is better. Rewriting C crap in Rust is a public service. The faster we can get eOS of C and C++ the better.

[–] Solemarc@lemmy.world 10 points 1 week ago (1 children)

I know we've all heard Microsoft and google say that 70% of their bugs are memory safety issues, but the GNU core utils don't really have that problem. They're small, simple, short lived programs and most of the problems they have arent memory related.

Most of the CVE's we've seen since Ubuntu picked the rust version up are logic issues and race conditions.

[–] onlinepersona@programming.dev 2 points 1 week ago (1 children)

Regardless of how secure and safe GNU coreutils are, requiring people to learn a memory unsafe language in order to contribute isn't good. It's the same as having COBOL control most of the financial system and other legacy systems. It's better to rewrite those things in modern languages early on than 50, 70 or 100 years later.

Bugs will occur, that's hardly an argument against progress nor is it an argument for standing still. It's good that bugs existed. It was a learning opportunity for the rust core utils. We learn by making mistakes. The people involved in the bug fixing and those who read the bug reports undoubtedly learned a thing or two that they can use to improve the rust ecosystem and bring to other projects.

CVEs exist and will continue to exist as long as software exists. Logic CVEs will probably exist forever, but practically eliminating an entire class (memory safety CVEs) allows concentrating on logic. I'd argue that's a much better way forward.

[–] MonkderVierte@lemmy.zip 7 points 1 week ago* (last edited 1 week ago) (1 children)

There's not much to contribute there. They are small simple utilities some Unix admin wrote for their own convenience some 50 years ago. The equivalent to a little shell script, where they had not much shell yet.
GNU overengineered them a bit and that's it.

Their point is, that every system has them, with the same interfaces and behavior everywhere.
If you have to rewrite them, make them better but name them differently. Like tools like ripgrep, fd, bat and the like.

[–] onlinepersona@programming.dev -1 points 1 week ago* (last edited 1 week ago) (1 children)

Wy rename them? This exactly gives people the opportunity to contribute stuff to standard tooling without having to go through a mailing list and with a much better developer experience.

Yes, it's on Microslop Github, but I have hope they'll see the light and move away from that AI riddled big tech platform. At the latest when forgejo or another forge implements federation.

[–] MonkderVierte@lemmy.zip 5 points 1 week ago* (last edited 1 week ago) (1 children)

Wy rename them?

Because they have to work 100% like the original tools otherwise. I will not write compatibility checks for the -rs set in my scripts and likely nobody else too. Even POSIX compatibility is often already expected too much.

[–] onlinepersona@programming.dev -2 points 1 week ago (1 children)

Why so they have to work 100% like the original tools? Why can't it overlap and add more? Why can't it remove features that are confusing or a security liability?

[–] MonkderVierte@lemmy.zip 1 points 1 week ago* (last edited 1 week ago)

Would you eat a brown Pizza? It's still a Pizza. A Alpenpizza.

Spoiler

[–] sobchak@programming.dev 8 points 1 week ago

I like C. Rust is better, but I like the simplicity of C too. C++ is an abomination :)

[+] ThomasWilliams@lemmy.world -7 points 1 week ago (1 children)

I doubt whether the original code even considered race conditions. That would have been left to script developers to figure out.

rust-core-utils is not completely compatible nor does it replace all functionality of core-utils. It's essentially useless for compliation or configuration scripts before we even discover all the bugs it probably has in it.

Memory safety is useless if the language is such a pig to program it's almost impossible to write bugfree code.

[–] gnufuu@infosec.pub 1 points 1 week ago* (last edited 1 week ago)

I doubt whether the original code even considered race conditions. That would have been left to script developers to figure out.

Are you saying that coreutil devs have been ignoring race conditions for the past 30 years? Because that would be an odd thing to be wrong about.

[+] Sanctus@anarchist.nexus -20 points 1 week ago (2 children)

Rust is so obviously a cuck licensing grift for corpos that it even does the corpo thing! Dont worry about why it is just remake it so I dont have to pay or recognize anybody.

[–] gravitas_deficiency@sh.itjust.works 14 points 1 week ago

[–] TehPers@beehaw.org 9 points 1 week ago (1 children)

You're right. The only reason someone would write something in Rust is to change the license. Nobody would use Rust for any other reason, nor would they use any other language for that purpose.

[–] Sanctus@anarchist.nexus 1 points 1 week ago (1 children)

Then what's this push to rust everything? Even shit thats not a particular risk for memory safety?

[–] anti_antidote@lemmy.zip 9 points 1 week ago (1 children)

Have you considered that maybe it's just pleasant to write software in?

Programming

Rules

Wormhole