Thanks for the post @jimmycuadra! This has definitely been on my mind at least from time to time, and I wanted to write down some of my thoughts on this in addition to those already mentioned here.
From a technical perspective, I would basically just like to have a canonical solution for various crypto needs. If you want to do things like SSL, hashing, or asymmetric ciphers we should have some crate for this in the ecosystem (not necessarily all in the same crate). Unfortunately I don't think we've quite gotten to this point in the ecosystem, but I think that we're definitely on the way there! My opinion is that once we start to see crates like this emerge we could perhaps consider moving to the nursery and then eventually into rust-lang itself (in accordance with the RFC for rust-lang crates) to have it be a blessed solution for the Rust community at large.
It will likely be quite a long time before we're comfortable having this kind of functionality in std itself, but the purpose of RFC 1242 was to spell out how the libs team will help manage the ecosystem beyond std as well as even having an almost "extended std" with the rust-lang crates. Progress has been somewhat slow on this front, but we're still trying to keep the pipeline full!
So talking less long-term, I also have some thoughts about the state of things today. Applications like Cargo and users of hyper need SSL support, and there are already crates doing various kinds of hashing here and there (e.g. crates.io). For this the choice of OpenSSL is usually made (as you've noticed), but it comes with the standard drawbacks of what you mentioned, "being OpenSSL", difficult to find on Windows, difficult to link on OSX, and not even the easiest thing to link to on Linux. I would agree as well that the Rust API of
rust-openssl may need an audit, but I wouldn't necessarily call the situation dire! I suspect that if the libs team talked a bit with @sfackler we could bang out a std-like-quality API in less than a week in addition to drastically improving the usage documentation for how to interface with the library. I know I would personally enjoy auditing the API at least for docs, usage, patterns, etc.
In the near future I'm also pretty excited about projects like @briansmith's
ring, they seem like they've definitely got some huge potential in terms of cryptography-at-large in Rust itself. This of course is always a long uphill battle as trusted libs for security have quite high standards (rightfully so).
So with all that in mind, here's what I think the next steps here should be:
- Revamp and audit the API surface of
rust-openssl. Bring it up to std-like quality and approach it with an eye of stabilization.
- Try to improve the story for cross-platform crypto (using the native system APIs). For example this may mean a library that uses OpenSSL on Linux, Security.framework on OSX, and the Cryptography API on Windows. I doubt this library would be
rust-openssl exactly, and there are bits and pieces of this today in the ecosystem, but it hasn't all been tied together.
- Consider moving a crypto-related crate to the nursery. This may be
rust-openssl or perhaps even this "cross platform" library, but movement into the nursery will help messaging in terms of "this is the first thing you should try" as well as help improve the API/platform support story over time.
- In the long term look towards implementing everything in Rust itself (ala
ring and friends). Once we've got traction of Rust basically everywhere, lots of buy in, and lots of enthusiasm this may "just fall out"
I'm pretty excited to see where crypto goes in the future, and I think there's even a few things we can do in the short term to greatly improve the experience. Hope that all makes sense!