You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, it is possible to build Themis against OpenSSL 3.0 without apparent major issues. However, Themis is still using APIs deprecated in OpenSSL 3.0. Additionally, Themis has not been extensively tested with OpenSSL 3.0 and there might still be some subtle issues remaining, especially compatibility issues.
Current status
For the time being, Themis requires OpenSSL 1.1.1 (on platforms where this is applicable; many use BoringSSL). Themis still builds and works with OpenSSL 1.0.2 and 1.1.0, but those are not supported anymore, please upgrade.
OpenSSL 3.0 is not supported until it is. Users are free to build from source however they like, but our supported packages are going to continue using OpenSSL 1.1.1.
Investigate test suit failures with OpenSSL 3.0 (#875)
While Themis builds (with deprecation warnings), unit tests have some failures in asymmetric cryptography, suggesting improper API usage. Those issues need to be corrected, they possibly affect OpenSSL 1.1.1 as well.
Stop using deprecated API in Themis Core
Themis necessarily uses quite a few of low-level APIs which got deprecated in OpenSSL 3.0. This is not an immediate issue but might become one when distros start disabling those APIs in their OpenSSL builds. It is unwise to continue depending on deprecated API.
Preferably, Themis should just use new API for OpenSSL 3.0, but compatibility shims are an acceptable solution too.
Implement cross-testing OpenSSL 1.1.1 against OpenSSL 3.0
Themis data formats implicitly depend on some OpenSSL implementation details. We must ensure that keys and data are mutually understandable.
Implement transition for binary packages of Themis Core
For a while, we will need to support both flavors – linked against libcrypto.so.1 and libcrypto.so.3 – and that will require some packaging acrobatics.
Ensure that desktop wrappers are able to work with both Themis Core flavors
Provide OpenSSL 3.0 support in iOS wrappers (opt-in for now)
Clarify licensing changes brought by OpenSSL 3.0
Basically, it's Apache 2.0 all the way down now.
The text was updated successfully, but these errors were encountered:
Since #996 is merged, guess we can mark Stop using deprecated API in Themis Core as done. When compiled with 3.0, new APIs will be used. Meanwhile, 1.X remains supported and uses older 1.X APIs.
This is a tracking issue for OpenSSL 3.0 support.
Currently, it is possible to build Themis against OpenSSL 3.0 without apparent major issues. However, Themis is still using APIs deprecated in OpenSSL 3.0. Additionally, Themis has not been extensively tested with OpenSSL 3.0 and there might still be some subtle issues remaining, especially compatibility issues.
Current status
For the time being, Themis requires OpenSSL 1.1.1 (on platforms where this is applicable; many use BoringSSL).
Themis still builds and works with OpenSSL 1.0.2 and 1.1.0, but those are not supported anymore, please upgrade.
Outstanding items
Deny building Themis with OpenSSL 3.0 (#872)
OpenSSL 3.0 is not supported until it is. Users are free to build from source however they like, but our supported packages are going to continue using OpenSSL 1.1.1.
Investigate test suit failures with OpenSSL 3.0 (#875)
While Themis builds (with deprecation warnings), unit tests have some failures in asymmetric cryptography, suggesting improper API usage. Those issues need to be corrected, they possibly affect OpenSSL 1.1.1 as well.
Stop using deprecated API in Themis Core
Themis necessarily uses quite a few of low-level APIs which got deprecated in OpenSSL 3.0. This is not an immediate issue but might become one when distros start disabling those APIs in their OpenSSL builds. It is unwise to continue depending on deprecated API.
Preferably, Themis should just use new API for OpenSSL 3.0, but compatibility shims are an acceptable solution too.
Implement cross-testing OpenSSL 1.1.1 against OpenSSL 3.0
Themis data formats implicitly depend on some OpenSSL implementation details. We must ensure that keys and data are mutually understandable.
Implement transition for binary packages of Themis Core
For a while, we will need to support both flavors – linked against
libcrypto.so.1
andlibcrypto.so.3
– and that will require some packaging acrobatics.Ensure that desktop wrappers are able to work with both Themis Core flavors
Provide OpenSSL 3.0 support in iOS wrappers (opt-in for now)
Clarify licensing changes brought by OpenSSL 3.0
Basically, it's Apache 2.0 all the way down now.
The text was updated successfully, but these errors were encountered: