*Linux distro package maintainers screams
OpenSSL 4.0.0
71–80 of 89 posts
Re: OpenSSL 4.0.0
#72> 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)
Re: OpenSSL 4.0.0
#73Major version bump? I wonder how much slower it will get now.
Re: OpenSSL 4.0.0
#74How 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?
It’s still terrible. There was a brief period immediately after Heartbleed that it was rapidly improving but the entire OpenSSL 3 was a huge disappointment to anyone who cared about performance and complexity and developer experience (ergonomics). Core operations in OpenSSL 3 are still much much slower than in OpenSSL 1.1.1. The HAProxy people wrote a very good blog post on the state of SSL stacks: https://www.haprox…
This is incredible, and damning. What do the OpenSSL maintainers say in response to these criticisms?
Re: OpenSSL 4.0.0
#75Earlier quoted context omitted.
The top feature, “ Support for Encrypted Client Hello (ECH, RFC 9849)”, is of prime importance to those operating Internet-accessible servers, or clients; hopefully your Postgres server is not one such!
It's a web server (pg / post-quantum, not pg / Postgres), but that's a great feature!
gqgq
Er. Your first acronym is pg not pq. (I had to font test above to be sure!) But point taken! You might care then, I saw various elliptic changes and I assume it’s got pq advancements somewhere in it.
Re: OpenSSL 4.0.0
#76Earlier quoted context omitted.
It’s still terrible. There was a brief period immediately after Heartbleed that it was rapidly improving but the entire OpenSSL 3 was a huge disappointment to anyone who cared about performance and complexity and developer experience (ergonomics). Core operations in OpenSSL 3 are still much much slower than in OpenSSL 1.1.1. The HAProxy people wrote a very good blog post on the state of SSL stacks: https://www.haprox…
There are little other options. `Ring` is not for production use. WolfSSL lags behind in features a bit. BoringSSL and AWS-LC are the best we have.
BoringSSL has an unstable API, and Google specifically recommends against using it[1].
AWS-LC is ok, but afaict there aren't really any pre-built binaries available, and you need to compile it yourself, and is a little difficult to use if you aren't using c/c++ or rust. (The same is largely true of boringssl).
[1]: https://github.com/google/boringssl?tab=readme-ov-file#borin...
Re: OpenSSL 4.0.0
#77Earlier quoted context omitted.
Once upon a time, like today? ICMP is most definitely only allowed situationally through firewalls today.
That kind of cargo culted tradition is how you end up with weird packet loss and VPNs that flat-out refuse to work. I could be convinced to block inbound pings. Anything past that and I'd want solid evidence that it wouldn't break anything, with the expectation that it would.
address-mask-request and redirect and timestamp-request for IPv4 might be problematic to allow inbound from who knows where. echo-request might well be rate limited so remote hosts can ping certain servers (but not random client host IPs), but not too many pings per second.
Re: OpenSSL 4.0.0
#78Earlier quoted context omitted.
It’s still terrible. There was a brief period immediately after Heartbleed that it was rapidly improving but the entire OpenSSL 3 was a huge disappointment to anyone who cared about performance and complexity and developer experience (ergonomics). Core operations in OpenSSL 3 are still much much slower than in OpenSSL 1.1.1. The HAProxy people wrote a very good blog post on the state of SSL stacks: https://www.haprox…
Wow, also this: > The OpenSSL project does not sufficiently prioritize testing. [... ]the project was [...] reliant on the community to report regressions experienced during the extended alpha and beta period [...], because their own tests were insufficient to catch unintended real-world breakages. Despite the known gaps in OpenSSL’s test coverage, it’s still common for bug fixes to land without an accompanying regre…
OpenSSL is (famously) an extremely terrible codebase.
It's likely that over the long-term the tech industry will replace it with something else, but for now there's too much infrastructure relying on it.