This sort of blanket statement doesn't fill me with confidence. Rust can only ensure some of those things, and putting this much faith in your (admittedly very cool) tools Seems remarkably cavalier
It does not, however, follow that it will be free from leaks of secrets. There are plenty of ways to leak secrets which don't involve the program leaving its envelope of defined behavior. No language is free from that.
Now I wouldn't dare accuse Rust developers to be as terrible at writing secure code as the average K&R worshipper, and unlike the JVM most (all?) of Rust is actually written in Rust I hear, but I wouldn't flat out claim there won't ever be an arbitrary code execution vulnerability in a Rust project.
This isn't a flippant response: I suspect most RCEs in Rust software are likely to be high-level vulnerabilities like that.
Imagine now it is possible to construct an argument to those libsodium functions that satisfies the constraints of the Rust wrappers, but still manages to crash libsodium and execute some part of the argument, which is not unheard of since libsodium is written in C and it operates on blobs of data.
Now the only mistake the implementor of thrussh has to make is to allow for that input to be passed into the rust libsodium wrapper through the protocol implementation.
If you note the OP, he expressed it in terms of "high confidence" not a "claim there won't ever be an arbitrary code execution vulnerability in a Rust project". Which would be absurd. And it's also as good as it gets: you can't avoid vulnerabilities.
Most of those are of the form "malicious code delivered as Java applet can break out of the JVM sandbox". That is, they crucially rely on running untrusted code. By contrast, the threat model here involves attackers subverting existing, trusted code. Memory safety holes in Rust overwhelmingly rely on bizarre carefully crafted code that nobody would accidentally write.
There are some exceptions: Java is affected by serialization issues along the lines of the Rails YAML vulnerability, for instance. But most of those don't apply to Rust either for various reasons.
1) Bugs in native code (generally image processing, compression, etc). This code tends to be derived from existing libraries, and so shares common vulnerabilities.
2) Bugs in sandboxing when running untrusted code. Java's sandbox model is fundamentally flawed and I don't believe it can ever be secured.
3) Executing untrusted external user input within the JVM context, e.g., by evaluating external data using your internal scripting language that has access to the JVM or relies on JVM sandboxing.
Of those:
1) Not much you can do, but issues are relatively rare.
2) Can be avoided by not running untrusted code in a JVM-enforced sandbox (applets are dead, sorry).
3) You'll be fine if you steer clear of libraries that even go near eval() of untrusted user input. The culprits here are serial offenders due to architectural/design issues, and are easy to avoid (e.g. Apache Struts.)
Also, all you need to get remote execution is bad user input validation surrounding some instance of std::process::Command.
Though such cases have been few and far between, soundness bugs have shown up in Rust, and some oddities in the way RAII works have lead to the notion of Prepooping your pants[1] to avoid use-after-free bugs.
1 - http://cglab.ca/~abeinges/blah/everyone-poops/
Rust is a phenomenal language, and one I'm placing a lot of faith in, but it provides only very specific guarantees and it's unwise to assume it will protect you from more than it actually does
There's a huge difference between checking your program for memory model violations, and checking the compiler for correctness.
Given a program written 99.9% in safe Rust, and a minimum set of unsafe stubs (trivial enough to prove) to access outside world (syscalls), you can assume you're safe against RCE. The holes are more likely in the supporting logic outside your program - kernel, dynamic loaders, network stacks, debug/trace interfaces, row hammer, etc.
> Rust is a phenomenal language, and one I'm placing a lot of faith in, but it provides only very specific guarantees and it's unwise to assume it will protect you from more than it actually does
I do agree with this point, though. It guarantees you will not escape the envelope of a specific memory model and defined behavior, up to the boundary of "unsafe" blocks, and assuming the runtime environment is not interfered with externally. You still need all those externalities to be secure, and it does nothing for leakage through side-channels.
Right - and, if the description for the project had put it in those terms, I'd have felt the project deserved more of my trust. My problem was precisely with the dismissive tone in which it says "It's written in Rust so I'm immune to all these things", while not actually backing that statement with a half-decent justification for why Rust would help.