You're suggesting writing this stack in a GC language. That's possible, except most people looking for an OpenSSL solution probably won't be willing to take the hit of slower run time perf and possible GC pauses (even if these might be small in practice). Also, these are hypothetical for now. Rustls exists today.
OpenSSL was just an example. You could also use XML parsing or many other tasks.
Point is that the code already exists - it's not hypothetical - and has done for a long time. It is far easier to write bindings from an existing C API to a managed implementation than write, audit and maintain a whole new stack from scratch. There are also many other cases where apps could feasibly be replaced with code written in managed languages and then invoked from C or C++.
Anything written in C/C++ can certainly tolerate pauses when calling into third party libraries because malloc/free can pause for long periods, libraries are allowed to do IO without even documenting that fact etc.
I think it's fair to be concerned that rewrite-it-in-rust is becoming a myopic obsession for security people. That's one way to improve memory safety but by no means the only one. There are so many cases where you don't need to do that and you'll get results faster by not doing so, but it's not being considered for handwavy reasons.
I think the thing you’re missing is that opensource people love rewriting libraries in their favourite languages. Especially something well defined, like tls or an xml parser. Rustls is a great example. You wont stop people making things like this. Nor should you - they’re doing it for fun!
It’s much more fun to rewrite something in a new language than maintain bindings to some external language. You could wrap a Java library with a rust crate, but it would depend on Java and rust both being installed and sane on every operating system. Maintaining something like that would be painful. Users would constantly run into problems with Java not being installed correctly on macos, or an old version of Java on Debian breaking your crate in weird ways. It’s much more pleasant to just have a rust crate that runs everywhere rust runs, where all of the dependencies are installed with cargo.
> It is far easier to write bindings from an existing C API to a managed implementation than write, audit and maintain a whole new stack from scratch.
I’d agree, if rustls wasn’t already written, audited and maintained. And there are other examples as well. The internationalisation libraries Icu4c and Icu4j exist, but the multi-language, cross-platform library Icu4x is written in Rust. Read the announcement post on the Unicode blog (http://blog.unicode.org/2022/09/announcing-icu4x-10.html?m=1) - security is only one of the reasons they chose to write it in Rust. Binary size, memory usage, high performance. Also compiles to wasm.
Your comment implies that people rewrite in Rust for security alone. But there are so many other benefits to doing so.
No, I’m imagining cross-language usage. Someone not using Go isn’t going to use the crypto/tls package from the Go std lib regardless of its quality. The overhead and difficulty of calling into Go make this infeasible.
To include a library written in another language as a shared lib, it needs to be C, C++ or Rust.
Or just write a better crypto stack without the many legacy constraints holding OpenSSL back. Rustls (https://github.com/rustls/rustls) does that. It has also been audited and found to be excellent - report (https://github.com/rustls/rustls/blob/main/audit/TLS-01-repo...).
You're suggesting writing this stack in a GC language. That's possible, except most people looking for an OpenSSL solution probably won't be willing to take the hit of slower run time perf and possible GC pauses (even if these might be small in practice). Also, these are hypothetical for now. Rustls exists today.