TLS [Re: Review of gnio, round 2]

[Dan Winship <danw gnome org>]

Alexander Larsson wrote:
> No GSocket methods are virtual, so its not possible to subclass GSocket
> and override methods to e.g. create a TLS/SSL socket. The current TLS
> code in gnio works on the higher level stream objects rather than the
> socket object, but it would possibly be interesting to have TLS at the
> GSocket level too. This would mean making all GSocket methods indirect.

Well...

g_socket_send_to() and g_socket_receive_from() are already just wrappers
around g_socket_send_message() and g_socket_receive_message()
respectively, and I'm not sure why g_socket_send()/g_socket_receive()
aren't just wrappers too...

In order to properly integrate with our main loop, the TLS library is
going to have to expose its file descriptors publicly, which means all
of the fd-related calls don't need to be virtual. (Maybe there would
need to be property notifications when the fd properties change, in case
the TLS library needs to account for the changes internally as well.)

It needs to be possible for the application to control when TLS
negotiation starts (eg, for "STARTTLS" type protocols), so
g_socket_connect() could be non-virtual, and would just require an
additional call to be made after it if you want to start TLS right away.

g_socket_accept() is a bit trickier; obviously you sometimes want to be
able to do TLS on the result of accepting a socket. So either we'd have
to make accept() virtual, and have listening GTLSSockets return
GTLSSockets from accept(), or else make it not virtual, but have it be
possible to convert a GSocket to a GTLSSocket.
(g_tls_socket_new_from_socket()? Though really, the GTLSSocket would not
be wrapping the GSocket, it would be stealing its fd, so we might want
some name that was more explicit about that.)

So basically it ends up only being send_message, receive_message,
create_source, condition_wait, and condition_check (and maybe accept)
that need to be virtual. (The GIOCondition-related ones are because of
the handshaking trickiness, where the application is waiting to read
from the socket, but the TLS layer is actually waiting to write to it,
or vice versa.) Probably some code reorganization could be done on the
GIOCondition-related ones to make it only necessary to have 1 or 2
virtual methods instead of 3.


Another possibility would be to just put all of the logic for TLS into
GSocket itself, with call-outs to some extension point for the actual
implementation. If we don't imagine ever having any other subclasses of
GSocket, then this might make sense...

-- Dan