OpenSSL 3.0 (or 4.0) API goals

[Matt Caswell]

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.

>  * Avoiding non-portable types in the API (the most obvious example:
>    using "int" as the type for socket descriptors, which is only
>    portable to Windows due to an implementation detail).

I would hope that we're not introducing any new instances of this. Any that we
have are likely to be historical. Removing such instances would be a matter of
deprecating the relevant APIs and making sure they have suitable portable
replacements in place.

>  * Possibly using something like uint8_t* for pointers to buffers
>    containing binary "stuff" (this could be more annoying than helpful,
>    requiring a lot of casting, so I'm not sure about that).
> 
> Just wondering... seems like a good time to think about cleanups like
> that, if feasible.
> 



On 02/03/2019 09:18, Angus Robertson - Magenta Systems Ltd wrote:
> Also replacing all C macros such as those for SSL_CTX_ctrl with proper
> external functions.
>
> This will ease use of OpenSSL with languages other than C, where we
> currently have to code functions to replace the macros.
>
> Google did this when creating BoringSSL, there may be other similar
> 'improvements' that could help OpenSSL.

I'd be in favour of that for SSL_ctrl/SSL_CTX_ctrl where I don't think the
"ctrl" pattern adds much value. All SSL_METHOD implementations share the same
ctrl implementation, with the exception of DTLS which adds a few extra ctrls.

For other areas that may not be the case. For example with BIO_ctrl all the
different BIO_METHODs all have quite separate ctrl implementations so there
seems a bigger benefit to this pattern there.


Matt