Deprecation

[Dmitry Belyavsky]

Dear Matt,

On Fri, Feb 14, 2020 at 12:48 PM Matt Caswell <matt at openssl.org> wrote:

>
>
> On 14/02/2020 09:41, Dmitry Belyavsky wrote:
> > Hello,
> >
> > 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
> gone wrong.
>

Totally agree. Though the conversion between engines and providers is not
as straightforward as I want, so I prefer to wait for some time.

>
> 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.
>

Sure.

>
> 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.
>

Hmmm. Not sure here. I remember the introduction of EVP_PKEY_ameth/pmeth
currently moving to providers.

>     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.
>

It's worth explaining the benefits to engine authors :)
I understand the benefits of OpenSSL as a product and still now don't have
a firm understanding of benefits for the surrounding ecosystem. Though I
did not dive into the providers deeply.

I still have a suspicion that we will not have function signatures for
callbacks in providers.
Do we? If don't, we'll have a set of errors implementing it.

> 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.
>

Sure.


> > 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.
>

Totally agree.

-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20200214/10227cac/attachment.html>