[gst-devel] TCP Plugins w/ OpenSSL

[Jim Muchow]

We feel obligated to return the changes we've to the Gstreamer
community.

We understand that there is a licensing mismatch between 
Gstreamer and OpenSSL. That said, based on a little research,
the solution here, the approach, would seem to work for GnuTLS
as well as OpenSSL. We hope that this can be of help should 
someone else need this functionality.

This update contains the README file and the patch file we use.

Thanks,
Jim Muchow

-----Original Message-----
From: Jim Muchow [mailto:jim.muchow at updatelogic.com] 
Sent: Thursday, January 20, 2011 12:26
To: Discussion of the development of GStreamer
Subject: Re: [gst-devel] TCP Plugins w/ OpenSSL

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

------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
gstreamer-devel mailing list
gstreamer-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: README
Type: application/octet-stream
Size: 1790 bytes
Desc: README
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20110214/004c63e5/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: supportForOpenSSL.diff
Type: application/octet-stream
Size: 42122 bytes
Desc: supportForOpenSSL.diff
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20110214/004c63e5/attachment-0001.obj>
-------------- next part --------------
_______________________________________________
gstreamer-devel mailing list
gstreamer-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel