Re: [PATCH] Ssl::PeerConnector class

On 23/04/2014 10:41 p.m., Tsantilas Christos wrote:
> On 04/22/2014 10:18 PM, Amos Jeffries wrote:
>>
>> Hi Christos,
>> Alex and I have just reached a design agreement about how to manage
>> these modularizations going forward.
>
> Hi Amos,
>
>>
>> We have decided to construct a namespace Security:: in a library at
>> security/libsecurity.la which presents the polished neutral API for
>> accessing SSL features. Leaving the code presenting OpenSSL specific API
>> in ssl/*
>>
>> Since this class is already presenting a neutral API. Would you be able
>> to make this the first code moved to the new namespace Security::
>> (instead of Ssl::)?
>
> I will move it under the Security:: namespace if needed.
> Does the Security namespace refers to SSL connections? Will it be a
> layer to support multiple SSL libraries?

It refers to the system for securing connections, of which SSL is one
form of doing so.

Yes, able to, although right now OpenSSL is the only one supported.

>
> In this patch, the PeerConnector has dependencies to OpenSSL library. I
> do not know if it can be considered as an independent part.
> However removes the openSSL related code from FwdState.cc file.

The important part is that the library API does not include OpenSSL
specific symbols for embeding into external code. So that it can
(eventually) be linked against unconditionally regardless of its
dependencies.
So,
 The internals of the library code (when enabled) can reference OpenSSL
and/or the src/ssl/*.h objects as needed.
 The security/*.h can be use #if USE_OPENSSL, but carefully so as not to
present conditional symbol names (ie for typedefs, inline methods etc
but not hiding the class from non-OpenSSL builds).

The model for this is the ip/libip.la interception code. Where the API
presents a OS-neutral API always linked against and the internals of the
Intercept.cc contain all the complicated #if-#endif logics for dependencies.

>
> Should the PeerConnector.* files moved under a new "security/" folder?

In my plan yes.

If this is getting too complicated or confusing, please fee free to just
commit what you have and I am happy to followup with the shuffling.

Amos
Received on Wed Apr 23 2014 - 11:36:30 MDT