3 ms·
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 F
by bluejekyll 11y ago
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.
- sgrove 11y agoWhat about binding to the OCaml implementation at https://nqsb.io/ https://nqsb.io/ ?
- nostrademons 11y agoWouldn'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.
- sgrove 11y agoGood point, I think it would indeed mean pulling in all of OCaml's runtime model.
- jononor 11y agoDoes 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.
- bluejekyll 11y agoIn 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.
- jononor 11y agoProblem 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.