[gst-devel] TCP Plugins w/ OpenSSL

[Jim Muchow]

> From: Sebastian Dröge [mailto:sebastian.droege at collabora.co.uk]
> Sent: Thursday, January 20, 2011 11:30
> 
> On Thu, 2011-01-20 at 11:58 -0500, Jim Muchow wrote:
> > We’ve implemented OpenSSL in the TCP portion of the Base
> Plugins. We
> > would like to contribute this code to the Gstreamer project, but
> we
> > don’t know how. We also have some questions/concerns and some
> > unfinished work.
> >
> > Rather than dive into the technical details, I’ll just leave it
> here.
> >
> > Comments? Questions?
> 
> You mean to tcpserver{sink,src} and tcpclient{sink,src}? I guess

I do. 

We've implemented and tested the changes to tcpclientsink & tcpserversrc.
Each of the functions in gsttcp.c now have an OpenSSL analog.

> that's a good idea in general but the problem here is, that the
> OpenSSL license is not GPL compatible and as such this code can't
> live in gst-plugins-base.
>
> As alternative you could add a compile-time option to use either
> OpenSSL or GnuTLS.

The code has been implemented (in the 0.10.29 release) using a conditional
compile. If not included, a resulting build binary is identical to one 
prior to this feature addition. If included in a build, however, the use 
of OpenSSL can be enabled or disabled via the set_property mechanism.

> Apart from that it might make sense to create new elements for
> this in -base, that share a lot of code with the TCP elements...
> instead of having a enable-SSL/TLS property on the elements.

There at least a couple of approaches to how integrate with TCP. One is
to use the OpenSSL BIO abstraction. The other way is to let a sockets-based
environment "do its thing" (socket(), listen(), accept(), connect()) and 
then bolt on an SSL session. We chose the latter. If former is preferred,
then yes, a whole new set of elements would make sense.