No argument from me that you can easily go wrong in any language, but I would argue that Rust has features other than memory safety that can also assist in building more reliable/secure software.
back
1 comments
Such as?
The Rust type system can define parts of the state machine that can help guarantee certain states are true at compile time.
This is very helpful for not using cryptography libraries incorrectly, or not accidentally using the wrong data at different points of implementing functions.
Generally more applicable to higher level use cases, the ring[1] library is a great example of how the algorithms (same impls as OpenSSL) are exposed to end users.
I like Ring but I don't think there's a lot of evidence that Rust's type system has effectively prevented cryptography errors, either in protocol state machines or in primitive implementations.
The challenge in avoiding cryptography mistakes is that you have to understand the errors before you can avoid them. Short of formal analysis with provers, I don't think there's a level of programming rigor that gets you away from most (maybe any?) of the last 10-15 years of (say) {TLS,JWT} bugs.
I look forward to discussing that on the 25th when we have more information.
Evidence of this nature will always be difficult, though, since it’s very difficult to prove a negative. We can only prove that some specific issue hasn’t yet occurred.
Match statement exhaustiveness checking is one example, especially combined with the pervasiveness of enums (instead of constants).
Any respectable C compiler does this.
What C compiler has pattern matching and ADTs?
Every C compiler these days will warn about unchecked enums in switch statements. This is, effectively, what the comment was saying.
Pattern matching has nothing to do with security or program safety.
Like the one OpenSSL is being compiled with?