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. 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 levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/