OpenSSL 3.0 (or 4.0) API goals

[Richard Levitte]

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

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

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.