> This means that this library will never be subject to arbitrary code execution, leaks of secrets, buffer overruns, double frees, etc.
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
I think it's fair to have a high level of confidence in freedom from arbitrary code execution, buffer overruns, double frees, etc.
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.
Though I would love to agree with you, Java also promised to fully protect us from arbitrary code execution. In some ways even stronger than Rust. But as we all know Java has been riddled with code execution bugs.
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.
I'm actually curious now – is it possible to deliberately introduce an RCE vulnerability into Rust code with `#![forbid(unsafe_code)]`? Has anyone done it?
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.