beldmit at gmail.com
Fri Feb 14 11:08:28 UTC 2020
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
> > 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.
> 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.
> > 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.
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openssl-project