OpenSSL 3.0 (or 4.0) API goals
levitte at openssl.org
Mon Mar 4 12:08:40 UTC 2019
Matt Caswell <matt at openssl.org> skrev: (4 mars 2019 12:59:26 CET)
>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
Incidentally, I looked at clang-tidy today. It seems to have some helpful options for this kind of work.
>> * Signed vs. unsigned values for integer values
>We did do quite a bit of work internally in libssl to implement more
>use of size_t where appropriate. We need to do something similar in
>although that's probably a much bigger job. Dealing with things
>much easier than changing the API - because that is obviously a
>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
>have are likely to be historical. Removing such instances would be a
>deprecating the relevant APIs and making sure they have suitable
>replacements in place.
>> * Possibly using something like uint8_t* for pointers to buffers
>> containing binary "stuff" (this could be more annoying than
>> 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
>> 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
>"ctrl" pattern adds much value. All SSL_METHOD implementations share
>ctrl implementation, with the exception of DTLS which adds a few extra
>For other areas that may not be the case. For example with BIO_ctrl all
>different BIO_METHODs all have quite separate ctrl implementations so
>seems a bigger benefit to this pattern there.
Sent from my Android device with K-9 Mail. Please excuse my brevity.
More information about the openssl-users