Closed bifurcation closed 3 years ago
In general I totally agree with the idea of having as much SRTP code written in Rust.
I would also strongly suggest to use bindgen as much as possible, to avoid problems by hand written binding code.
Is the end goal here to have a pure Rust SRTP crate and another crate with the bindings for C? That setup has the advantage that pure Rust implementations do not have to pull in the bindings code if they don't need it.
@nils-ohlmeier Yes, that's the end goal I had in mind, a Rust crate with C bindings on top for those who need them. The idea of gradually migrating over libsrtp code was to ensure correctness as the migration is done.
There is some tension here between idiomatic Rust and compatibility with C (including other parts of libsrtp). For example, libsrtp's crypto agility is done with function pointer tables, which might not be how you would do it in Rust.
Logistically, since this is going to take a little while it would probably be best to create a feature branch and land PRs to that.
A rust implementation exists today https://github.com/webrtc-rs/srtp it was ported from https://github.com/pion/webrtc
Supports SRTP_AES128_CM_SHA1_80
and SRTP_AEAD_AES_128_GCM
. Is it missing any features that stop it from being useful today?
Closing this while I come up with a more thoroughly worked-out proposal.
Since libsrtp handles packets directly off the network, before any authentication has been done, it should have stronger protections against memory corruption. This PR proposes a way to work toward a migration to Rust:
libsrtp_rs
library within the libsrtp code baseThis strategy assures that API and test invariants are maintained through the migration. It also lets consumers select when they want to move over. In the long run, of course, the goal would be to have a pure-Rust library with a C API to support legacy consumers.
At this point, Rust integration is only supported with the CMake build, and requires that the corrosion CMake extension be installed. To build with Rust: