<div dir="ltr"><div>Dear Richard,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 14, 2020 at 1:37 PM Richard Levitte <<a href="mailto:levitte@openssl.org">levitte@openssl.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 14 Feb 2020 10:41:05 +0100,<br>
Dmitry Belyavsky wrote:<br>
> <br>
> <br>
> Hello,<br>
> <br>
> On Fri, Feb 14, 2020 at 5:30 AM Dr Paul Dale <<a href="mailto:paul.dale@oracle.com" target="_blank">paul.dale@oracle.com</a>> wrote:<br>
> <br>
>     There is some pushback against the deprecations going on in various PRs.<br>
>    <br>
>     The plan has always been to deprecate engines in 3.0 and removing support for them 5+ years later. <br>
>     Originally, the path was to have included an engine provider that could load engines and make them appear<br>
>     to be a provider.  After a fair amount of investigation, this was deemed to be too difficult in the 3.0<br>
>     time frame.<br>
>    <br>
>     Do we still want to deprecate engines in 3.0?<br>
>     Should we defer until 4.0 instead?<br>
> <br>
> I think we should delay the deprecation of engine stuff to 4.0. Personally I don't have sense of stability of<br>
> provider API.<br>
<br>
It should be pointed out that the engine stuff isn't as stable as you<br>
might think, because it shares internal structures with libcrypto.<br>
Even if we handle those structures via function calls, all it takes is<br>
loading an engine linked against - say - 1.1.0 in 1.1.1 to run a real<br>
risk of a spectacular KABOOM if any of the structure that are touched<br>
changed between those OpenSSL versions.<br></blockquote><div><br></div><div>Does ABI compatibility cover a significant share of these cases?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
This is a consequence of making structures opaque and feeling much<br>
more liberty in changing them, and we didn't quite pay attention.<br>
<br>
The whole model around providers is intentionally designed to allow<br>
providers to run flexibly with any OpenSSL version, even if they are<br>
linked with some (possibly different) libcrypto version.<br>
<br>
So the question of stability depends on what you look at.<br></blockquote><div><br></div><div>Agreed. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
It's true that some parts of the provider API is fluctuating a bit, as<br>
early designs need modifications to better meet demands.  We're still<br>
in development.  Come beta1 (schedule for June), I expect that it will<br>
have stabilized.  Come the release, it must have.<br></blockquote><div><br></div><div>Sure.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>     The main benefits seem to boil down to continuing to support existing engines vs removing the legacy code<br>
>     paths and switching to the provider model.<br>
> <br>
> For me, both as open-source and commercial engine developer seems<br>
> reasonable to delay conversion from engines to providers at least<br>
> until 3.0.0 feature freeze happens.<br>
<br>
According to our policy, a deprecation starts at the release that has<br>
those deprecations, and removal of deprecated stuff can only happen 5<br>
years later at the earliest.  Seeing deprecations in the source now<br>
doesn't change that, the clock will start ticking when we release<br>
3.0, so consider what you see happening on github as a pre-deprecation<br>
warning.<br></blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> But some features I'm interested in imply engine model (and it will<br>
> be great if somebody else could look at PR 10904 to avoid it when<br>
> possible).<br>
<br>
Apart from a few details, that PR looks rather innocuous.  I frankly<br>
haven't had time to look at it too deeply (I just discovered that I<br>
was prompted), as I haven't dived in the CMS code yet...<br></blockquote><div><br></div><div>Well, the problem is introducing some new control values. I don't feel policy here very well.</div><div>I also plan to submit at least one TLS-related PR significantly more innocent...</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature">SY, Dmitry Belyavsky</div></div>