Deprecation

[Dmitry Belyavsky]

Dear Richard,

On Fri, Feb 14, 2020 at 1:37 PM Richard Levitte <levitte at openssl.org> wrote:

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

Does ABI compatibility cover a significant share of these cases?


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

Agreed.

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

Sure.

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

Yes.


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

Well, the problem is introducing some new control values. I don't feel
policy here very well.
I also plan to submit at least one TLS-related PR significantly more
innocent...

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