Dear Richard, On Fri, Feb 14, 2020 at 1:37 PM Richard Levitte <levi...@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.d...@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
