GNOME Bugzilla – Bug 761092
glib-networking: merge tls split
Last modified: 2017-10-17 20:15:00 UTC
The tls split branch refactors out some of the code from the gnutls backend creating some base classes that can be used by other implementation, i.e the openssl one. One of the reasons to not merge this was the conflicts it would get with the DTLS merge, though we know already that the dtls support will not get merged this release so I wonder if we should get this already in. It has been tested with gnutls and openssl.
Created attachment 319687 [details] [review] Add a generic HAVE_TLS flag to build the tests
Created attachment 319688 [details] [review] Split tests to take into account the backend
Created attachment 319689 [details] [review] tls: split out non-gnutls-specific code from gnutls backend Create GTlsConnectionBase, GTlsInputStreamBase, GTlsOutputStreamBase, which implement the generic "translate from a BSD-sockets-y API to the GTlsConnection API" semantics, and rebase GTlsConnectionGnutls on top of that.
(In reply to Ignacio Casal Quinteiro (nacho) from comment #0) > One of the reasons to not merge this was the conflicts it would get with the > DTLS merge, though we know already that the dtls support will not get merged > this release so I wonder if we should get this already in. It has been > tested with gnutls and openssl. Given that this changes a lot of code, but doesn't add any new functionality (for gnutls users), I think it would be better to wait until after 2.48.0, and then merge this right after branching so there's plenty of time to shake out bugs before it hits a stable release.
(In reply to Dan Winship from comment #4) > Given that this changes a lot of code, but doesn't add any new functionality > (for gnutls users), I think it would be better to wait until after 2.48.0, > and then merge this right after branching so there's plenty of time to shake > out bugs before it hits a stable release. Is it a good time to merge this in master now?
Now that glib-openssl is a separate module, this is not needed anymore, right Ignacio? I don't think extending glib-networking to support multiple TLS backends is a good idea, since it will make glib-networking maintenance significantly more difficult, will result in us maintaining a backend that is effectively a second-class citizen, and it's already possible to completely replace the entire GTlsBackend. I suspect it's better for both glib-networking and glib-openssl for these to be maintained as separate modules going forward. Do you agree?
Hey Michael, yeah I think it makes sense to close this bug report. BTW maybe it makes sense to have a look at glib-openssl's last patches since we fixed several vulnerabilities pointed out by testssl.sh and maybe it might make sense to port them to glib-networking
I'll definitely check out testssl.sh, didn't know about that. BTW I don't see any commits there that look immediately useful for glib-networking, except the one that disables rehandshaking entirely (which doesn't seem desirable?). Is there any one in particular that you want to suggest we take?
> Now that glib-openssl is a separate module, this is not needed anymore, right Ignacio? FWIW the plan had always been that glib-openssl would be a separate module and not supported by the GLib maintainers. This bug was just about abstracting out the parts that could be shared between the two modules. (Though we never figured out for sure if the next step was "move those parts into glib as public types", "create a glib-networking-devel with those types" or "just let glib-openssl cut+paste them".)