Withdrawal of OpenSSL 3.0.6 and 1.1.1r | Hacker News Reader

Withdrawal of OpenSSL 3.0.6 and 1.1.1r

mta.openssl.org

107 pointsTimWolla9 comments

Vote to stop shipping 3.0.6 and 1.1.1r (https://github.com/openssl/general-policies/pull/32)

- Regression: X509_sign, etc., no longer implicitly refresh the cached TBSCertificate (https://github.com/openssl/openssl/issues/19388)

- PKCS12_parse leaves errors on stack [3.0.6] (https://github.com/openssl/openssl/issues/19389)

3.0.6 was released 3 days ago: https://mta.openssl.org/pipermail/openssl-announce/2022-Octo... and apparently had "Fix for custom ciphers to prevent accidental use of NULL encryption ([CVE-2022-3358])"

https://www.openssl.org/news/vulnerabilities.html#CVE-2022-3...

1.1.1r was "Added a missing header for memcmp that caused compilation failure on some platforms"

Those are just the only cited major changes, not the only changes in those releases. See the full changelogs:

- 3.0.6: https://www.openssl.org/news/cl30.txt

- 1.1.1r: https://www.openssl.org/news/cl111.txt

Did these changes cause performance issues? The original post doesn't really explain what the main problem was.

No idea, but a "non security regression" almost always has to be performance with OpenSSL, I'd think.

Or it stopped building on some platform.

Good news. I observed those AES cipher/lz2-v2 issues with dead tunnels on newer builds of OpenVPN, on i5-8265u CPU but not on R5 3600. Had to rollback on a previous release.

Another W for my habit of not upgrading our application's embedded OpenSSL library until there's an actual relevant security bug fix.

We also dodged the serious bug introduced in 3.0.4 that way.

Does the rule about versioning still hold? Are they still blowing smoke in everyone's eye and keeping their security audit's results by incrementing a sub-patch letter in their version number, even though they make major breaking changes between each release?

The other day my cluster went down because the rules for "self-signed certificates" changed between releases, and a certificate signed by a different CA with a similar Common Name was now rejected as "self-signed" by the client library.

What's the point of suffering a naming scheme this silly if we can expect major breakage between each release anyway?

Is there a reason LibreSSL seems less bumpy than a multicorp sponsored OpenSSL? Is it just more development takes place in OpenSSL vs LibreSSL?

Reply on news.ycombinator.com