On 06/09/2014 11:26 PM, Nathan Scott wrote:
[ ... ] given that most people wont be
using encryption/non-af_unix authentication at all. I wonder
if we could get crafty and load the secure sockets support in
an "on-demand" fashion?
We do have both forms of networking still there in the code of
course - could we find a way to bootstrap in the security libs
only if they are actually needed? (i.e. run time linking, via
dlopen(3) trickery, instead of compile time linking).
For the NSS/NSPR/SSL layers, I think that the main complication, for
servers, is that, at the time a socket is created for accepting a
connection, it isn't known whether that socket will need to be secure.
However, it may end up being just an extra step in the connection
process at the end of the day. We already have connections which are
upgradable from insecure to secure from a protocol point of view. It
could be as easy as upgrading a native socket to NSPR before doing that.
The API
https://developer.mozilla.org/en-US/docs/PR_ImportTCPSocket
seems to be available for this purpose, although there are some caveats
expressed there. Despite those caveats, they (Mozilla) seem to be
promoting the use of this function.
If we were to go this route, then the native socket handle and APIs
would be used for sockets on both the client and server side under
normal circumstances. When an operation requiring a secure socket is
attempted, then libpcp could automatically import the handle into NSPR.
I believe that this could be done automagically without the knowledge of
the caller by simply adding the NSPR bits to the handle's entry in the
IPC table. The caller would continue to use the same handle, but the
operations would be automatically mapped to NSPR calls. I can see this
potentially eliminating the current native/NSPR division in the IPC table.
The dynamic loading NSPR/NSS/SSL libraries would be done the first time
they are needed, if ever.
Dave
|