[alpaca128]

As a fan of the language I also don't get this. I mean I welcome wider adoption of Rust for various reasons, but this whole "it's written in Rust!" checkbox filling doesn't have any connection to what matters in reality.

If you're rewriting something anyway, or creating something new then Rust should be considered. But a lot of the value of old software is not the set of features listed in the Readme. Not every area comes with its own "don't roll your own crypto" warning, but almost everything has its share of edge cases and quirks that were already handled in existing tools.

[pdimitar]

Would you feel better about this is if the badge was "Written in a memory-safe language"?

[cerved]

tbh, I would feel better if the badge was "tested for 50 years on every system you can think of"

[pdimitar]

I, too, enjoy sci-fi. :)

[cerved]

cat has been around for 49 years and 8 months, give or take a few days

[pdimitar]

Sure, there are a few of these around. 99% of the software you use every day has been around for less however.

[cerved]

yeah but not on this list

[hulitu]

Is a memory-safe language a safe language ? Is it not possible to exploit rust ?

[pdimitar]

Of course it is possible. If you get your hands on the binary itself there's nothing that a good reverse-engineer will not be able to do.

Point however is, if you have a SaaS which uses Rust, the chances for triggering a buffer underflow / overflow exploit are zero.

As for other aspects of security, Rust makes no special effort there. The main win for using Rust is to eliminate the most widespread bugs (the memory safety ones) from the get go. Everything else is still fair game and has to be paid proper attention to.

[clappski]

> the chances for triggering a buffer underflow / overflow exploit are zero

Doesn't the mere existence of unsafe make this untrue? From a quick google I can see at least one[1] so the chances are definitely a lot higher than zero

[1] https://github.com/servo/rust-smallvec/issues/252

[burntsushi]

The GP is either being incorrectly absolutist, or left out an important qualifier: "In safe Rust, the chances of <insert memory safety problem here> are zero."

But that is also absolutist. Instead, you might say, "In safe Rust, the chances of <insert memory safety problem here> are zero, modulo bugs in the compiler."

But that's not quite the fully story either. So instead, you might say, "In safe Rust, the chances of <insert memory safety problem here> are zero, modulo bugs in the compiler or any dependencies or any other uses of 'unsafe' in your application."

And maybe that's still not quite it. So let's try again: "In safe Rust, the chances of <insert memory safety problem here> are zero, modulo bugs in the compiler, any dependencies or any other uses of 'unsafe' in your application and any other platform specific tricks for arbitrarily rewriting memory used by your process."

That probably covers it. But it's a mouthful. It's probably best to avoid saying the chances of anything are zero. Instead, the key value add of Rust is that it flags areas of code that permit introduction of UB for easier auditing, and also enables building safe---for all inputs---abstractions for others to use. But humans are fallible, so there is and always will be an opportunity to fuck something up somewhere. What Rust gives you over something like C or C++ is a way to make assumptions that are more fine grained than, "I trust that every line of code written in the transitive dependency chain is free of UB."

[clappski]

Thanks, that last bit clears it up for me. I've never touched Rust but write C++ everyday so don't really know much about what is guaranteed vs. what is less likely due to borrow checking/compiler verifaction

[pdimitar]

What I simply meant was "it's quite hard to introduce memory non-safety in Rust in a normal everyday work". But your explanation is definitely much more precise.

[sweeneyrod]

I don't think memory safety bugs are the most widespread kind at all, unless you add the qualification "in languages with manual memory management".

[steveklabnik]

I imagine what they're alluding to is that it seems like most of the security bugs are memory-safety related. The number is about 70%, and has been replicated independently at a number of places.

That is of course a very different thing!

[pdimitar]

Yeah, seems I messed up some words. :(

But yes, I meant the majority of the security bugs indeed.

[username90]

Rust isn't a memory safe language though. Unsafe is a part of the language, so it wouldn't get that badge.

[pirocks]

Pretty much ever safe language has unsafe features though, either by calling out to C or something like sun.misc.Unsafe in java.

[username90]

Calling unsafe libraries isn't the same thing as having unsafe language features.

[alpaca128]

Calling unsafe libraries automatically makes the calling code unsafe by definition. You cannot have a 100% safe language that also interacts with its (unsafe) environment in any way.

The language needs a way to express the lack of safety of an external library in order to clearly isolate it from the safe code sections. In Rust that's the unsafe block.

[pdimitar]

`cargo-geiger` provides nice detailed output. I found it eye-opening and it made me more conscious what dependencies to use.

[pdimitar]

unsafe{} is an explicit escape hatch so it's much easier to audit and control for. So you are simply nitpicking.

[valenterry]

To me it makes sense. I predict the future of the tool/product partly on the technology, and the programming language is part of it

[pxc]

I wonder if in the future, it will be easier to find contributors for Rust projects than C projects, just because Rust is more pleasant to use.