OpenSSL 3.0 (or 4.0) API goals

[Matt Caswell]

On 04/03/2019 12:57, Hubert Kario wrote:
> On Monday, 4 March 2019 12:59:26 CET Matt Caswell wrote:
>> On 01/03/2019 22:26, Paul Smith wrote:
>>> Hi all.
>>>
>>> I'm reading with interest the details coming out with respect to the
>>> next release of OpenSSL.
>>>
>>> I'm curious if there's any consideration being given to updating the
>>> API for existing interfaces, and/or checking the APIs of any new
>>> interfaces for issues that are seen in the current API.
>>>
>>> I'm talking about things like:
>>>  * Const-correctness for arguments
>>
>> const correctness is an ongoing thing. I'd welcome PRs that address this.
>>
>>>  * Signed vs. unsigned values for integer values
>>
>> We did do quite a bit of work internally in libssl to implement more
>> consistent use of size_t where appropriate. We need to do something similar
>> in libcrypto although that's probably a much bigger job. Dealing with
>> things internally is much easier than changing the API - because that is
>> obviously a breaking change which we try to avoid where possible.
> 
> In the past 9 years OpenSSL broke ABI/API 2 times (0.9.x to 1.0.0 and 1.0.2 to 
> 1.1.0) and announced a third. I think it's far too often for such a critical 
> and integral part of operating systems.
> 
> IMNSHO such API cleanup should be mandatory part of the OpenSSL 3.0 (4.0) 
> deliverable.
> 

Well what we said about OpenSSL 3.0 is:

"OpenSSL 3.0 is a major release and will be a significant change to the internal
architecture of OpenSSL. We plan to keep impacts on existing end user
applications to an absolute minimum with the intention that the vast majority of
existing well-behaved applications will just need to be recompiled. No
deprecated APIs will be removed in this release."

(from my blog post).

And:

"The OpenSSL 3.0 release will have minimal impact to the vast majority
of existing applications; almost all well-behaved applications will
just need to be recompiled."


So ABI compatibility won't be maintained. But I expect API compatibility largely
will. I do not expect the 1.1.1 -> 3.0 move to be anything like the 1.0.2 ->
1.1.0 move. While a recompile will be necessary, the intention is that, in most
cases, that will be all.

Matt