It's true. In my DNS code I have zero unsafe code. Though I did need to add some new unsafe code to the Rust OpenSSL library, but that's really because of the FFI to C. That too would be unnecessary if OpenSSL was rewritten in Rust.
Wouldn't that require pulling in the OCaml garbage collector? Much of the reason people use glibc or other low-level libraries rather than a managed runtime is so they don't need to link in a managed runtime.
Does the OpenSSL library allow/plan for an Rust reimplementation (possibly side-by-side for a while) of the C bits?
Seems that would be best practice - assuming the goal is make everything safe Rust.
In theory that's just copying the Rust bridge code and using that as the frontend API for a rewrite. So yes it's possible, you "just" need to rewrite the rust-openssl-sys library.
I think the hesitation there is that everyone has gotten it beaten into your head that writing new crypto libraries is dangerous. It's probably safer to use a library that has tons of eyes on it, but at some point we should do it.
Problem is that if this is not considered beforehand, one might create APIs which are very hard/tedious to replicate without the old/legacy implementation.
But maybe for openssl staying close to the original API is useful, then one could maybe put a C API on top and use it also outside Rust.
