Hacker News Reader

Comment by phendrenad2 | Hacker News Reader

You don't know what you're asking for. In reality, you'll end up replacing C code with memory unsafely with Rust code written by people who understand Rust less than they understand C. The problem? The Rust Evangelism Strike Force always assumes that if you replace a C program with a Rust program, it'll be done by a top-tier expert Rust programmer. If that isn't the case (which it won't be), then the whole thing falls apart. There are vulnerabilities in JS and Ruby code, languages that are even easier (and just as type-safe) as Rust.

View on HN

There's something to be said for taking the entire class off vulnerability off of the table.

For instance, in the past I worked at a sort of active directory but in the cloud company. We identified parsers of user submitted profile pictures in login windows as a privilege escalation issue. We couldn't find memory safe parsers for some of these formats that we could run in all these contexts, and ended up writing a backend service that had memory safe parsers and would recompress the resulting pixel array.

Rust parsers at the time would have greatly simplified the workflow, and I'm not sure how we would have addressed the problem except as whack-a-mole at the time if there wasn't our central service in the middle (so MMS can't do that).

This is just incorrect. The beauty of Rust is even bad programmers end up writing memory safe code because the compiler enforces it. The ONLY rule an organization needs to enforce on their crappy programmers is not allowing use of unsafe. And there are already available tools for enforcing this in CI, including scanning dependencies.

I think what they're saying is that by making devs use a less familiar language, you're going to end up with at least as many security bugs, just ones not related to memory safety. (Not weighing in either way, just clarifying.)

Keeping mind that, if you have an RCE bug, any other class of bug is irrelevant. It's a bit like diagnosing someone with the flu after their head has been cut off. And while acknowledging that you're not personally weighing in either way, I will personally call the idea that you'll end up with just as many bugs of a weaker class to be quite silly. Everyone starts as unfamiliar in every language, but not every language makes it equally easy to accidentally introduce vulnerabilities. Defaults matter, tooling matters, and community norms matter, and all of these make it less likely for a low-quality Rust programmer to introduce vulnerabilities than even a medium-quality C programmer.

> There are vulnerabilities in JS and Ruby code, languages that are even easier (and just as type-safe) as Rust.

This is completely misleading. The vulnerabilities that exist in those languages are completely different. They often are also far less impactful.

Memory safety vulnerabilities typically lead to full code execution. It is so so so much easier to avoid RCE in memory safe languages - you can grep for "eval" and "popen" and you're fucking 99% done, you did it, no more RCE.

Rust programmers can write buggy code, but you'd really have to go out of your way to write memory-unsafe code.

I think the only question that matters is how much longer it takes to write a moderately-sized program in Rust vs C. If it takes around the same time, then an average C programmer will probably write code with more bugs than an average Rust programmer. If it takes longer in Rust, the Rust programmer could start taking some seriously unholy shortcuts to meet a deadline, therefore the result could be worse.

All code can have bugs, it's mostly just a question of how many. Rust code doesn't have to have zero bugs to be better than C. It's not like all C programmers are top-tier programmers and all Rust programmers are the bottom of the barrel.

This is part of the issue though:

Writing things in C correctly takes more time than in rust (once you get past the initial learning curve)

Writing things in C that appear to work may take less time.

I think we can be reasonably sure that Apple didn't introduce those image parsing bugs intentionally. But that means they thought it was correct.

I've written a few things at work in C/C++ and Rust. I can move much faster in Rust, personally, as long as the pieces of the ecosystem I need are there. Obviously I only speak for myself.

Part of that is because I'm working in code where security is constantly paramount, and trying to reason about a C or C++ codebase is incredibly difficult. Maybe I get lucky and things are using some kind of smart ptr, RAII and/or proper move semantics, but if they're not then I have to think about the entire call chain. In rust I can focus very locally on the logic and not have to try and keep the full codebase in my head

That assumes that writing unsafe code would make you go faster. It wouldn't. In general if you want to write code in Rust more quickly you don't use unsafe, which really wouldn't help much, but you copy your data. ".clone()" is basically the "I'll trade performance for productivity" lever, not unsafe.

Rust doesn't need top tier programmers. It just needs competent programmers.

The C in use today wasn't written by experts either. And if it was, we can leave it alone for now, or at least until said experts get tired of maintaining it.

I'm surprised no one has mentioned OpenBSD yet. Theo touches on this topic in this presentation: https://www.youtube.com/watch?v=fYgG0ds2_UQ&t=2200s

Some follow-up commentary: https://marc.info/?l=openbsd-misc&m=151233345723889

Because it's not relevant.

1. In the video he's saying that you can't replace memory safety mitigation techniques like ASLR with memory safe languages. He notes that there will always be some unsafe code and that mitigation techniques are free, so you'll always want them.

No one should disagree with that. ASLR is effectively "free", and unsurprisingly all Rust code has ASLR support and rapidly adopts new mitigation techniques as well as other methods of finding memory unsafety.

2. The link about replacing gnu utils has nothing to do with memory safety. At all.

Even if it were related, it would simply be an argument from authority.

Reply on news.ycombinator.com