3.0.6 was released 3 days ago: <a href="https://mta.openssl.org/pipermail/openssl-announce/2022-October/000235.html" rel="nofollow">https://mta.openssl.org/pipermail/openssl-announce/2022-Octo...</a> and apparently had "Fix for custom ciphers to prevent accidental use of NULL encryption ([CVE-2022-3358])"<p><a href="https://www.openssl.org/news/vulnerabilities.html#CVE-2022-3358" rel="nofollow">https://www.openssl.org/news/vulnerabilities.html#CVE-2022-3...</a><p>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.<p>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?<p>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.<p>What's the point of suffering a naming scheme this silly if we can expect major breakage between each release anyway?