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