OpenSSL 3.0 (or 4.0) API goals

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

OpenSSL 3.0 (or 4.0) API goals

Paul Smith
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
 * Signed vs. unsigned values for integer values
 * 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).
 * 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.

Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL 3.0 (or 4.0) API goals

Angus Robertson - Magenta Systems Ltd
> 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.

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.

Angus

Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL 3.0 (or 4.0) API goals

Matt Caswell-2
In reply to this post by Paul Smith


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

Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL 3.0 (or 4.0) API goals

Richard Levitte - VMS Whacker-2


Matt Caswell <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL 3.0 (or 4.0) API goals

Hubert Kario
In reply to this post by Matt Caswell-2
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.

--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky┼łova 115, 612 00  Brno, Czech Republic

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL 3.0 (or 4.0) API goals

Matt Caswell-2


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