Tracking Issue for Rust rewrite

[tyler274]

Hi,

This issue will track design discussions for the Rust rewrite. I already have a byte-for-byte compatible drop in re-implementation with formal verification (excluding the crossing of the FFI boundary) to adjust.

@simo5 Mentioned "not caring" for Async code, but unfortunately the LibVerto dependency is functionally that already. I'm open to using the MIO library which underpins Tokio to use lower level primitives, but unless we are targeting embedded devices I don't see a reason why we can't depend on Tokio itself. I don't consider this a personal blocker, and can rewrite things as requested.

[simo5]

The mio library is reasonable, and can be used to deal with sockets.
In order to introduce rust in a project like this we need to use a divide and conquer approach.

We need to identify parts that can be isolated and that make sense to convert to rust.

The server can be converted to rust and may make sense to do so, the gssapi mechglue (and therefore the client) really doesn't make much sense, it would just be a lot of FFI-rust-FFI translation with no much safety gain.

[tyler274]

The server can be converted to rust and may make sense to do so, the gssapi mechglue (and therefore the client) really doesn't make much sense, it would just be a lot of FFI-rust-FFI translation with no much safety gain.

The client and interposer were rewritten as more of a proof I could do that anyway. My downstream consumer mainly cared about the server anyway.

They were interested in seeing libgssapi itself be rewritten, including the existing kernel mode services, with more being moved into user space.

Thank you for the feedback by the way.