Deprecation

Tomas Mraz tmraz at redhat.com
Fri Feb 14 16:59:32 UTC 2020


On Fri, 2020-02-14 at 16:17 +0000, Salz, Rich wrote:
> I think we should delay the deprecation of engine stuff to 4.0.
> Personally I don't have sense of stability of provider API.
>  
> I share this concern.  This is the first release of the provider
> infrastructure, and while it will be known to work for FIPS modules,
> it’s hubris to think OpenSSL will get it completely right for other
> uses.
>  
> All other deprecations point to existing API’s or, if they are brand
> new, are not a lot of code/work to implement them.  The provider
> interface is both brand new and significant work.  Deprecating and
> saying “use providers” without at least one release cycle of 
> providers, seems premature.

This is an argument for not removing engines in 4.0 (or earlier than
one major release after the provider interface fully stabilizes and
proves viable). However I do not think that it is argument for not
deprecating it. Deprecation is declaration of intent and not a way to
force people stop using the API immediately.

How is the provider API going to improve/stabilize, if the 3rd party
engine suppliers will not get the the message that the engine API is
eventually going away in future and start writing providers as
replacement.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




More information about the openssl-project mailing list