Revert OPENSSL_NO_SSL3_METHOD to keep ABI compatibility.
Details
Details
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
No Lint Coverage - Unit
No Test Coverage - Build Status
Buildable 31955 Build 29505: arc lint + arc unit
Event Timeline
Comment Actions
Er, why? CURRENT is not ABI stable and SSLv3 is very broken. Applications that want to use a broken cipher can get that from ports.
Comment Actions
Because you cannot get stable branches ABI-stable if head is not. Yes, we keep ABI stable across branches, otherwise it is of little use.
For head we do not consider ABI breakage as the end of world but rather just a bug that needs to be fixed to bring HEAD back to the correct ABI.
Comment Actions
Because you cannot get stable branches ABI-stable if head is not.
I don't understand this remark, can you elaborate? Thanks.
Comment Actions
I we allow breaking ABI in head intentionally (and not transiently), then binary built for stable/X cannot be run on stable/(X+1).
Comment Actions
Sure, and sometimes that's fine.
For example, when we moved from openssl 1.0 to 1.1 in base, that broke ABI for anything linking against base openssl.
When we removed gets() from libc, that broke ABI for anything that linked the gets() symbol.
The solution here is to not break most things most of the time. Removing SSL3 is a good use of the limited exception to the general rule. Binaries that want to depend on known-broken parts of OpenSSL should link a specific version from ports. SSL3 (1996) has had security smell since as early as 2005 (early SHA1 weaknesses) and was completely broken in 2014 with POODLE; it was deprecated in 2015.
The real ABI bug here is that we shipped FreeBSD 12.0 in 2018 (and earlier, FreeBSD 11.0 in 2016) with SSL3 at all. It was broken and deprecated prior to both major releases.
Comment Actions
We did not, because the dso version was bumped.
When we removed gets() from libc, that broke ABI for anything that linked the gets() symbol.
We did not removed gets from libc, it is still there.
The solution here is to not break most things most of the time. Removing SSL3 is a good use of the limited exception to the general rule. Binaries that want to depend on known-broken parts of OpenSSL should link a specific version from ports. SSL3 (1996) has had security smell since as early as 2005 (early SHA1 weaknesses) and was completely broken in 2014 with POODLE; it was deprecated in 2015.
Point of binary compatibility is that you have the binary continuing working. If you force somebody to relink the binary it is exactly the reverse of ABI stability.
And if somebody cannot relink, he is left with a broken system that cannot be fixed.
The real ABI bug here is that we shipped FreeBSD 12.0 in 2018 (and earlier, FreeBSD 11.0 in 2016) with SSL3 at all. It was broken and deprecated prior to both major releases.
Opinions about deprecation of SSLv3 are irrelevant for technical question of ABI stability. Since symbols were not removed from libssl.so.111 when stable branch was declared stable, they must be present in libssl.so.111.
Comment Actions
We could provide dummy implementations of these symbols, rather than enabling SSLv3 code in 2020 in our unreleased development version of FreeBSD.
That is an interesting definition of ABI stability. I do not think it is a useful one. When we bumped SONAME, we also removed the old DSO version, breaking any program that linked to it. Removing an entire DSO SONAME is a bigger ABI break than a handful of SSLv3 symbols.
The solution here is to not break most things most of the time. Removing SSL3 is a good use of the limited exception to the general rule. Binaries that want to depend on known-broken parts of OpenSSL should link a specific version from ports. SSL3 (1996) has had security smell since as early as 2005 (early SHA1 weaknesses) and was completely broken in 2014 with POODLE; it was deprecated in 2015.
Point of binary compatibility is that you have the binary continuing working. If you force somebody to relink the binary it is exactly the reverse of ABI stability.
And if somebody cannot relink, he is left with a broken system that cannot be fixed.
Bumping SONAME is worse than removing SSLv3 symbols in all of these respects.
The real ABI bug here is that we shipped FreeBSD 12.0 in 2018 (and earlier, FreeBSD 11.0 in 2016) with SSL3 at all. It was broken and deprecated prior to both major releases.
Opinions about deprecation of SSLv3 are irrelevant for technical question of ABI stability. Since symbols were not removed from libssl.so.111 when stable branch was declared stable, they must be present in libssl.so.111.
I'm not sure that's really true. Anyway, if we must, we can provide dummy symbols.
Comment Actions
In which way ?
I am not aware of any other possibilty to keep ABI stable for non-symvered DSOs [*]. If you make breaking change like removing symbol, but not bump dso' version, user does not have even theoretical way to run old binaries (tricks with libmap or LD_LIBRARY_PATH are laborious and often worse than the original problem). If the version is bumped, old and new dso can co-exist on the same system. We provide the set of libraries for which version was bumped in HEAD (X + 1), as misc/compatX-<arch> port, ensuring that old binaries can still run.
- Technically libcrypto and libssl are symver-ed, but their symbol version scripts are not maintained for ABI stability, so for this discussion the libs can be considered not-symvered.
The real ABI bug here is that we shipped FreeBSD 12.0 in 2018 (and earlier, FreeBSD 11.0 in 2016) with SSL3 at all. It was broken and deprecated prior to both major releases.
Opinions about deprecation of SSLv3 are irrelevant for technical question of ABI stability. Since symbols were not removed from libssl.so.111 when stable branch was declared stable, they must be present in libssl.so.111.
I'm not sure that's really true. Anyway, if we must, we can provide dummy symbols.