OpenSSL 4.0.0

petecooper 237 points 77 comments April 14, 2026
github.com · View on Hacker News

Discussion Highlights (14 comments)

capitol_

Finally encrypted client hello support \o/

yjftsjthsd-h

As a complete non-expert: On the one hand, looks like decent cleanup. (IIRC, engines in particular will not be missed). On the other hand, breaking compatibility is always a tradeoff, and I still remember 3.x being... not universally loved.

ge96

Just in time for the suckerpinch video

jmclnx

I wonder how hard it is to move from 3.x to 4.0.0 ? From what I remember hearing, the move from 2 to 3 was hard.

georgthegreat

https://www.haproxy.com/blog/state-of-ssl-stacks According to this one should not be using v3 at all..

rwmj

Compared to OpenSSL 3 this transition has been very smooth. Only dropping of "Engines" was a problem at all, and in Fedora most of those dependencies have been changed.

caycep

How is OpenSSl these days? I vaguely remember the big ruckus a while back, was it Heartbleed? where everyone to their horror realized it was maybe 1 or 2 people trying to maintain OpenSSL, and the OpenBSD people then throwing manpower at it to clear up a lot of old outstanding bugs. It seems like it is on firmer/more organized footing these days?

bensyverson

I just updated to 3.5x to get pq support. Anything that might tempt me to upgrade to 4.0?

pixel_popping

Mythos is coming for yaaaaa (just kidding).

theowaway

oh no not another breaking ABI change

Neywiny

Good to see const more prevalent. Too often I have to add that in to libraries for embedded. Possibly I believe in const by default but it is what it is at this point

GZGavinZhao

*Linux distro package maintainers screams

cookiengineer

> libcrypto no longer cleans up globally allocated data via atexit(). > OPENSSL_cleanup() now runs in a global destructor, or not at all by default. Oh oh. Heartbleed 2.0 incoming. I really do hope that they broke APIs specifically throwing errors or race conditions so that devs are forced to cleanup. Otherwise this is going to be a nightmare to find out in terms of maintenance and audits. I mean it's a new major release so it's a valid design change. But I hope they're thinking of providing and migration/update guide or a checklist to reduce usage errata. (I'm heavily in favor of deprecating the fixed version method names)

semiquaver

Major version bump? I wonder how much slower it will get now.

Semantic search powered by Rivestack pgvector
4,562 stories · 42,934 chunks indexed