Re: [PATCH] Ssl::PeerConnector class

On 04/23/2014 05:36 AM, Amos Jeffries wrote:

> So,
> The internals of the library code (when enabled) can reference OpenSSL
> and/or the src/ssl/*.h objects as needed.

I am not sure that is a good rule. Maintaining an interface-level
separation of OpenSSL-reliant code from all other code would be better
than sprinkling common code with #ifdefs because #ifdefs inside a method
do not provide a good separation boundary.

If possible, we should restrict security/* to OpenSSL/GnuTLS-neutral
code IMO.

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

I think this should be committed as is, we need to agree on security/*
composition rules, and then the shuffling can start. The final
security/* design should not be too complicated or confusing, but it is
not fully thought through yet IMO.

The difficult work on providing an OpenSSL-neutral API is already done
so that part would be easy to move. If we decide that security/ can be
polluted with OpenSSL-specific code, the rest can be moved as easily. If
we decide against that, more serious changes would be required for that
move to happen.

Cheers,

Alex.
Received on Wed Apr 23 2014 - 15:08:53 MDT