While OpenSSL is among the building blocks of the Internet, I find NSS to be a higher quality library, mostly because it doesn't break API like OpenSSL does, but also because it's a more complete solution that comes with an OS abstraction layer (thanks to NSPR) a certificate storage component, and lots of other goodies. Not to mention the elephant in the room that is OpenSSL's abysmal track record, but that can change very fast for NSS as well so I don't think it's the biggest factor when comparing the two. At the end of the day, both are well-supported libraries.<p>The only area where OpenSSL wins hands down vs NSS is documentation, and by extension of its popularity, the easiness of googling a problem and finding its solution. As a comparison, I don't even know what the official NSS homepage is. But IME the source code of NSS is quite readable, so consider having another look at NSS if you need to deal with cryptography in your code.<p>Not a cryptographer, just a happy user, so YMMV.
> These are security-fix releases. The highest severity issue fixed in
each of these three releases is High:<p>And:<p>> HIGH Severity. This includes issues that are of a lower risk than critical, perhaps due to affecting less common configurations, or which are less likely to be exploitable. These issues will be kept private and will trigger a new release of all supported versions. We will attempt to keep the time these issues are private to a minimum; our aim would be no longer than a month where this is something under our control.
So the 1.0.2zg release is only for those paying $50,000 for the enterprise contract? That's understandable, but guess the people paying for lower tiers won't be very happy with that.<p>To be fair, this is clearly stated on their page.<p><a href="https://www.openssl.org/support/contracts.html" rel="nofollow">https://www.openssl.org/support/contracts.html</a>
Every time I've seen an OpenSSL security fix on HN, the discussion gravitated towards <i>alternatives</i>.<p>I think this is a wasted energy, because switching cryptographic providers is the last thing you want to do under the timeline of a routine security release for an open source library.<p>If you're a Debian user, this might be as simple as "ensure unattended-upgrades is configured on all hosts and this is monitored somehow". However, sometimes it's not so simple.<p>Eventually one of these releases is going to break something that requires a code change in your applications. (Maybe pass a different flag to OpenSSL? Maybe use a different API for, I dunno, MGF1+SHA256?) And I don't know how many teams are prepared for that kind of rollout.<p>I'd be interested in hearing from HN users how they plan to respond to these sort of releases.
I was told OpenSSL 3 was bad for the longest time, I used 1.1x for everything, but switched to Libressl.<p>Now that I need to switch to AWS Linux they are using OpenSSL 3, my question is should I still be hating on OpenSSL?