[arghwhat]

> Because rust inherently treats humans as fallible to a large extent. Which all of us are.

No it doesn't. It has a bypassable compile-time verified lifetime system, not an infallible programming guarantee. It leaves it entirely up to the developers to write correct and safe applications and libraries, and merely provides (powerful) tools to help.

(I realize this context was in avoiding common security bugs which are usually less likely in memory-safe languages, but it's important to not overstate the benefits.)

[cyber_kinetist]

I think Rust kinda has a marketing problem: the myth that "Writing in Safe Rust automatically makes your code memory-safe". It doesn't (well, it does most of the time but it isn't guaranteed), but it rather defers the responsibility to other low-level system programmers writing Unsafe code behind the scenes. And oh boy they have a fuckton of responsibility... Stacked Borrows along with various sanitizers can help when writing unsafe code, but it isn't perfect. I highly recommend anyone trying out Rust for the safety guarantees to take a look at the Rustonomicon (https://doc.rust-lang.org/nomicon/), which debunks a lot of the misconceptions around safe/unsafe Rust.

In an ideal la-la land world, there exists an abstract interpreter that can consume safe Rust code and does not enforce any contracts upon the programmer (and hence will never have any undefined behavior). However, real world hardware definitely has contracts which developers have to obey (manually! because of the constraints of actual semiconductor physics! no compiler hand-holding here!). And on top of that all major OSes (Windows, MacOS, Linux) are written in C (so you need unsafe FFI to interact with the OS).

[petergeoghegan]

There seems to be a perception among Rust programmers that C's status as a defacto standard came to be in spite of C's contradictions, rather than as a result of them. Skimming the Rustonomicon just now left me with the impression that at least one Rust person gets it. Though it still seemed as if the author felt the need to choose their words very carefully, lest they "make the memory model people angry".

[oconnor663]

The memory model people are intense but really quite friendly :) Here's a great recent post: https://www.ralfj.de/blog/2022/04/11/provenance-exposed.html

[dureuill]

exactly. if i'm writing safe rust and encounter memory safety issues, their origin is with my dependencies, and my responsibility is limited to having chosen such dependencies.

In practice, this makes vulnerabilities in eg. argument parsers (like the recent "baron samedit" vulnerability in sudo) incredibly unlikely.

[oconnor663]

> the myth that "Writing in Safe Rust automatically makes your code memory-safe"

Of course you're right that that isn't true as stated, but I think it's interesting to try to situate this point along a continuum of other similar points:

1. C with Valgrind and sanitizers isn't always memory safe, because those tools are limited by test coverage.

2. Python isn't always memory safe, because many libraries including the standard library call into C code.

3. Pure Python that doesn't call into any C code isn't always memory safe, because the interpreter might have bugs.

4. Provably correct Ada with a provably correct compiler isn't always memory safe, because the proof checker, the compile-time hardware, or the runtime hardware might have bugs.

I think we all agree that there are important differences between 1 and 4, beyond the simple fact that the defects get less common as you go down the list. Here are some things that stand out to me:

- In cases #2 and below, the application code isn't "at fault" for any memory unsafety that comes up, and whatever code is at fault can be fixed to restore memory safety without changing the application.

- In case #1, there's no clear boundary in any sense between "safe code" (which we know isn't at fault for memory unsafety) and "unsafe code" (which might be at fault). There may be a distinction between code that's well covered by tests and code that isn't, for example, but it's often not easy to tell which is which. In case #2 and below, the boundary is pretty clear.

- In case #1, the amount of "unsafe code" in an application probably grows linearly with the size of the application, or maybe we just consider the whole application unsafe. But in cases #3 and #4, unsafe code is confined to low-level dependencies that get a lot of "battle testing" compared to how much code is in them. Case #2 is kind of a gray area, and we need to look at what dependencies the application is using.

So where should we situate Rust in that continuum? Is being able to write unsafe Rust code more or less risky than being able to call into C? It's certainly a lot more convenient to write an `unsafe` block than to cross the FFI barrier, and maybe that convenience is dangerous. On the other hand (contrary to some common misconceptions), unsafe Rust still benefits a lot from the borrow checker and other safety features, and it might end up having a lower rate of defects for that reason. Maybe it's too early to tell?

But anyway yes, I totally agree that the Rust community has a hard time getting the messaging right about how safe code and unsafe code work. But even though this discussion is really important to Rust, I'm not sure it's a "Rust problem" per se. I think it's actually quite difficult to talk clearly and correctly and precisely about memory safety in general.

[ddevault]

http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust

"use-after-free", "data race", "memory corruption", "out-of-bounds write", "read from uninitialized memory", "execute arbitrary code"...

[ATsch]

This list is actually quite interesting for a few reasons.

One is that a large fraction of these security issues are not real, potentially exploitable vulnerabilities, but merely the fact that it is possible to abuse an API to subvert Rust's safety guarantees. These are things would, by the standards of other programming languages, not be worth even reporting and be considered user error.

The other is that a surprisingly large fraction of these are not from regular unsafe Rust code, but from misunderstanding the guarantees a C library makes when creating bindings for it. This is to be expected, as fully understanding those as a library is pretty difficult.

A total of one memory safety issue reported for an entire ecosystem this year so far also seems pretty good.

All in all, I think these are both pretty promising signs that the safety guarantees Rust provides working as intended.

[marcosdumay]

Wait, that's all? On the entire Rust ecosystem those are the only ones found?

Everybody already knows Rust has unsafe blocks and C FFI. It is not invulnerable to those problems, Rust just makes it very clear where those problems may appear, and if you are smart, you will place most of your code outside of those regions.

Looks like Rust is much safer on practice than what I expected.

[arghwhat]

Note that unsafe does not contain anything. The problem propagates to the unsuspecting caller of claimed safe code.

Ending up compromised by a problem in tokio, Pin semantics, actix or all the necessary ffi bindings is no different than, say, a C program being compromised by a vulnerability in OpenSSL or libcurl.

A very significant number of memory issues in C stemmed from issues in such single high-profile dependency, so one should not undermine the threat of a bit of unsafe code in the corner of a library.

[pierrebai]

Not being perfect does not translate to not being better. Being safe by default and having compiler-enforced safety as a top design choice is great.

Rust is better.

It's very much human nature to trace the line in the sand juuuuuust right behind one's heels though, depicting everyone behind as bad and everyone ahead as zealots.

[arghwhat]

I did not say rust was not better. I said the statement was false, based on a misunderstanding of both the benefits of Rust and the problems of C many if which Rust is not immune to.

Rust is definitely better, hands down, but insisting on thinking code that interacts with unsafe blocks can be "safe by default" is a dangerously wrong mindset which also makes unsafe blocks proliferate without the necessary caution as the problem seem "contained". Anyone remember the actix unsafe saga?

But even though a program with unsafe blocks (read: all rust programs) are by definition not memory safe - calling a language memory safe on current platforms can to some extend even be considered a misnomer - the assistance provided by rust by default certainly helps make such programs much safer.

[marcosdumay]

Yes, unsafe marks the places where your code must be correct no matter what. If it's wrong, the problems can appear anywhere.

That's very different from environments where all code must be correct no matter what. But the impact of bugs isn't what changes.

[scoutt]

Well... if you consider the proportion of "lines of code (or projects) ever written in the history of a language" over "security issues found" then Rust will be probably losing.

[marcosdumay]

A lot of those bugs are in C code...

[staticassertion]

You don't know what you're talking about re: security lol