Deprecation

[Richard Levitte]

On Fri, 14 Feb 2020 12:17:30 +0100,
Dmitry Belyavsky wrote:
> 
> 
> Dear Richard,
> 
> On Fri, Feb 14, 2020 at 1:37 PM Richard Levitte <levitte at openssl.org> wrote:
> 
>     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?

Yes.  Any structure change between those OpenSSL version potentially
means an ABI incompatibility between an engine and the libcrypto that
loads it.

This is precisely the reason why we have forbidden shared opaque
structures over the libcrypto <-> provider boundary.

...

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

We haven't formed a clear policy on those, it's a bit of play as we go
and do what makes most sense.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/