From 0c9afd6918dfe5e818b3545ede88011adeb6e76b Mon Sep 17 00:00:00 2001 From: Dmitry Belyavskiy Date: Tue, 23 Nov 2021 15:18:52 +0100 Subject: More detailed explanation how do engines work in 3.0 Related: #16868, #17081, #17107 Reviewed-by: Paul Dale (Merged from https://github.com/openssl/openssl/pull/17115) (cherry picked from commit 29a27cb2c5c1757831f42117871f8c59058343a9) --- doc/man7/migration_guide.pod | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/doc/man7/migration_guide.pod b/doc/man7/migration_guide.pod index 627173f180..67e102fa4c 100644 --- a/doc/man7/migration_guide.pod +++ b/doc/man7/migration_guide.pod @@ -121,6 +121,21 @@ FIPS module, as detailed below. Authors and maintainers of external engines are strongly encouraged to refactor their code transforming engines into providers using the new Provider API and avoiding deprecated methods. +=head3 Support of legacy engines + +If openssl is not built without engine support or deprecated API support, engines +will still work. However, their applicability will be limited. + +New algorithms provided via engines will still work. + +Engine-backed keys can be loaded via custom B implementation. +In this case the B objects created via L +will be concidered legacy and will continue to work. + +To ensure the future compatibility, the engines should be turned to providers. +To prefer the provider-based hardware offload, you can specify the default +properties to prefer your provider. + =head3 Versioning Scheme The OpenSSL versioning scheme has changed with the OpenSSL 3.0 release. The new -- cgit v1.2.3