A reminder that LibreSSL exists and has a fraction of the problems OpenSSL does.
At the AWS cryptography group, we've open-sourced our libcrypto - https://github.com/awslabs/aws-lc - which essentially tries to use the best from Google's BoringSSL, OpenSSL (from 1.1x , not 3.x) , our own code, and formal verification and does target a broad set of platforms and is our FIPS module.
We're at about 95% OpenSSL compatibility right now, it "just works" for a lot of applications, and I expect we'll get near-full compatibility this year as we switch more and more of our own systems to using it internally.
We don't promote it broadly, and it's not intended to compete with OpenSSL - but it's a may be an interesting option for some to consider.
It's surprisingly hard to get FIPS crypto in Golang on Windows.
Ahem. Cough.
Maybe I should leave this little link here for a patch published today ?
https://ftp.openbsd.org/pub/OpenBSD/patches/7.2/common/018_x...
But this is just one round of patches, I have no further information or experience on/with LibreSSL or how the features compare. Just saying that one patch release does not mean either secure or insecure software.
> "Release date for this was set to be January 31. Unilaterally pushed back to February 7 by OpenSSL by way of announcement of many completely unrelated embargoed issues, some of which they had been sitting on since July 2020"
https://github.com/rustls/rustls
Some thoughts on lessons learned from other projects/vulnerabilities:
The project has potential but isn't quite ready for prime time yet.
But for sure, taking a dependency on RusTLS from C code isn't a "boring" choice, and I wouldn't pretend to be confident that that would all go smoothly for a big project.