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"
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?
undefined
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)