I would like to officially announce that at NICE we have been working on a TLS backend for glib using Openssl. This still lives on the wip/openssl branch of glib-networking but hopefully next cycle we will manage to merge it to master.
Why are we not using the gnutls that is already implemented? There are a few reasons for it:
- We needed TLS support on Windows. You may say, but gnutls is built on windows with mingw! Well, we are using Visual Studio and it does not build with it.
- Our product has to run at least on RHEL 6, which means, we would have needed to port the current gnutls backend to the old version shipped there, it would have been possible but at the end of the day we wanted to have the same code base on both platforms.
- We depend also on cyrus-sasl which already depends on openssl, so we didn’t want to ship two TLS backends and have twice the bugs.
During the time that I spent implemented this backend I came to the conclusion that TLS is really hard! And it would have been harder if glib-networking didn’t have all those great unit tests. Thanks to all the people that wrote them.
This is also great for Android, where we could then just use the openssl shipped by the system instead of including yet another TLS stack with the application. The latter is what currently happens with GStreamer on Android.
I’d be very happy if this gets some testing on android as well.
Isn’t the OpenSSL license currently incompatible with the LGPL due to the advertising clause? Could you get the glib folks to add an OpenSSL exemption? https://people.gnome.org/~markmc/openssl-and-the-gpl.html
Yes thats why we added an exception which is already in master
You added the exception to YOUR code. But glib/gobject/gio is pure LGPL without the exception (and they will never add this exception).
I am not a lawyer but afaik it should be enough as I.e spice-gtk is not having such an issue.
Out of curiosity, was Mozilla’s NSS stack considered? That certainly qualifies a cross-platform option…
Yes, it was definitely considered and actually a branch is already around for a lot of years but was never merged. Though we would depend on a red hat module that is not upstream in order to have all the features we need. And actually the code split that was made on the nss backend in order to share the common code from the gnutls one was the starting point for the openssl one. I.e have a look at the wip/tlssplit and wip/nss branches. The other possibilities we took into account was to use the new lib from amazon and to make a native backend for windows using the winapi
Pingback: Visual Studio status for GTK+ builds | Nacho's Blog
Pingback: Ignacio Casal Quinteiro: Visual Studio status for GTK+ builds - Ur Guides