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.
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?
10 comments
[ 3.0 ms ] story [ 34.6 ms ] threadhttps://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"
- 3.0.6: https://www.openssl.org/news/cl30.txt
- 1.1.1r: https://www.openssl.org/news/cl111.txt
Or it stopped building on some platform.
- 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)
We also dodged the serious bug introduced in 3.0.4 that way.
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?