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
