I've read rustls source code and I understood what was going on. Same cannot possibly be said about OpenSSL.

Yes - used rustls on a new project rather than the openssl wrapper which we used before. The experience has been pretty good. The problems of shared library version inconsistency have gone. No noticeable downsides.

> The problems of shared library version inconsistency have gone. No noticeable downsides.

Sure, as long as you commit to releasing an updated version if a vulnerability is ever found in your version of rustls.

Edit: oh, and in such a case you should probably release your own CVE too, else not everyone will get the nudge to update.

Well our product was already something that included the openssl library, so we would have had to release a new version of our product when there's a patched version of openssl anyway.

At least updating it is easy now - we've put a lot of effort into that process recently.

OpenSSL is not great about compatibility. If you link to it dynamically, there is a good chance users have to recompile when it is updated which in practice means they'll need to update.

This theoretical advantage of shared libraries also doesn't materialize, if containers are used.

I do sympathize as I spend a lot of my time maintaining distro packages.

But I also fear that in this new world of golang and rust projects with statically linked libraries, few people take their reporting responsibilities seriously. Hell, if they did, a serious vulnerability in a commonly used library would result in an avalanche of CVEs.

Plenty of rust-based projects are using these libraries. I've yet to hear of a bad experience. I don't think there's much adoption outside of the Rust ecosystem.

For a newer project I'm surprised their documentation makes this recommendation:

> Next we load some root certificates. These are used to authenticate the server. The recommended way is to depend on the webpki_roots crate which contains the Mozilla set of root certificates.

The correct certificates to use are the ones that the OS says are trusted. Applications shouldn't ship with a cert bundle that overrides what I trust.

Earlier this year the ISRG made a post titled "Preparing ?Rustls for Wider Adoption" https://www.abetterinternet.org/post/preparing-rustls-for-wi... that references Curl, Apache, and Let's Encrypt.

Cloudflare uses ring, but not exclusively (last I heard).

I've used rustls with great success, and I'm really happy with it. Many projects have added support for it, such as curl.

However, I also still really welcome this announcement! There's a lot of code out there using OpenSSL, including both well-established libraries and new projects. I'm glad to see a new stable version of OpenSSL, with a better overall architecture and a more compatible license.

I've written a major server using ring and rustle. It just works and I'm confident in its security. By contrast openssl is a minefield.

I get stuck in a weird bug on certain Customer machine that suddenly start failing, so I replace the http client library to one that use rustls and gone.

A few hours of work and also the CI benefit!

P.D: Other software also fail the same, but they can't switch so fast... Rust refactoring is golden!