matt at openssl.org
Fri Feb 14 09:48:04 UTC 2020
On 14/02/2020 09:41, Dmitry Belyavsky wrote:
> On Fri, Feb 14, 2020 at 5:30 AM Dr Paul Dale <paul.dale at oracle.com
> <mailto:paul.dale at oracle.com>> wrote:
> There is some pushback against the deprecations going on in various PRs.
> The plan has always been to deprecate engines in 3.0 and removing
> support for them 5+ years later. Originally, the path was to have
> included an engine provider that could load engines and make them
> appear to be a provider. After a fair amount of investigation, this
> was deemed to be too difficult in the 3.0 time frame.
> Do we still want to deprecate engines in 3.0?
> Should we defer until 4.0 instead?
> I think we should delay the deprecation of engine stuff to 4.0.
> Personally I don't have sense of stability of provider API.
Well - it isn't stable *right now*. Its in development. But moving
forward the provider model *is* the way we intend to go. By the time of
the 3.0 release the provider stuff had better be stable, otherwise we've
As has been pointed out many times. Deprecation does not mean removal
(yet). Its just a signal that at some later time we will remove it.
And the 3.0 is the right time to signal that. We don't want to hold on
the "legacy" codepaths for any longer than we have to. They were only
ever originally intended to be temporary, and to be removed before 3.0
got released. However it now looks like they will live beyond the 3.0
release. They should not live for any longer than absolutely necessary.
> The main benefits seem to boil down to continuing to support
> existing engines vs removing the legacy code paths and switching to
> the provider model.
> For me, both as open-source and commercial engine developer seems
> reasonable to delay conversion from engines to providers at least until
> 3.0.0 feature freeze happens.
That's a perfectly reasonable strategy. But this decision is independent
of whether we deprecate the ENGINE APIs in 3.0 or not. It would be
perfectly ok for people to continue to *use* engines in 3.0 even though
they are deprecated.
> But some features I'm interested in imply engine model (and it will be
> great if somebody else could look at PR 10904 to avoid it when possible).
If there are gaps then we need to plug them. The provider model should
be able to do everything that you can do now in ENGINEs.
More information about the openssl-project