Deprecation

[Richard Levitte]

On Fri, 14 Feb 2020 10:41:05 +0100,
Dmitry Belyavsky wrote:
> 
> 
> Hello,
> 
> On Fri, Feb 14, 2020 at 5:30 AM Dr Paul Dale <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.

It should be pointed out that the engine stuff isn't as stable as you
might think, because it shares internal structures with libcrypto.
Even if we handle those structures via function calls, all it takes is
loading an engine linked against - say - 1.1.0 in 1.1.1 to run a real
risk of a spectacular KABOOM if any of the structure that are touched
changed between those OpenSSL versions.
This is a consequence of making structures opaque and feeling much
more liberty in changing them, and we didn't quite pay attention.

The whole model around providers is intentionally designed to allow
providers to run flexibly with any OpenSSL version, even if they are
linked with some (possibly different) libcrypto version.

So the question of stability depends on what you look at.

It's true that some parts of the provider API is fluctuating a bit, as
early designs need modifications to better meet demands.  We're still
in development.  Come beta1 (schedule for June), I expect that it will
have stabilized.  Come the release, it must have.

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

According to our policy, a deprecation starts at the release that has
those deprecations, and removal of deprecated stuff can only happen 5
years later at the earliest.  Seeing deprecations in the source now
doesn't change that, the clock will start ticking when we release
3.0, so consider what you see happening on github as a pre-deprecation
warning.

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

Apart from a few details, that PR looks rather innocuous.  I frankly
haven't had time to look at it too deeply (I just discovered that I
was prompted), as I haven't dived in the CMS code yet...

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/