As a C programmer myself I’m well aware of how big the mine field is, and I’m a big proponent for validation in the Rust style, but that was not the point.
This guide advocates for replacements for programs and libraries written in C++, with most of those replacements being written also in C++, but with “superior programming practices”, even when those replacements are very rarely used in most environments.
[0] https://trust-in-soft.com/
[1] https://www.eschertech.com/products/perfect_developer.php
[2] https://github.com/microsoft/Armada
[3] https://www.microsoft.com/en-us/research/project/vcc-a-verif...
Unfortunately this is easier said than done, as evidenced by the fact that it is said a lot, and never done.
I don't know how serious the rustls implementation is. Nice to see it makes no use of Rust's unsafe features.
> heartbleed was bad, but those type of bugs are rare
Not really. There's a constant stream of security vulnerabilities arising from buffer-overflows and memory-management bugs, even in the most high-profile C/C++ codebases like the Linux kernel and Chromium. C and C++ are minefields for undefined behaviour, and many security vulnerabilities can be tracked back to instances of undefined behaviour. Rewriting in a safe language, like SPARK or the safe subset of Rust, would close the door on these vulnerabilities.
That's not to say I'd uncritically jump aboard a safe-Rust replacement for OpenSSL. As you say, there's much value in mature and battle-tested code, and Rust's safety guarantees wouldn't guarantee you a bug-free SSL library, they only guarantee the absence of certain kinds of errors. Even a fully formally verified implementation in SPARK could still have side-channel vulnerabilities (e.g. timing issues).