GNOME Bugzilla – Bug 782853
glib-networking: Fails tests is system gnutls built without SSLv3
Last modified: 2018-01-07 21:41:27 UTC
Created attachment 352199 [details] tls test-suite.log If system gnutls is built without SSLv3 support (--disable-ssl3-support), glib-networking fails tests. This setting is getting common with POODLE in the past, etc. I'm not sure it makes sense to test SSLv3 fallback anymore, after bug 738633 and such?
This is related to bug #782218, where the %LATEST_VERSION_RECORD atom was removed from the priority string. Dan/Michael, does it make sense to drop some of the unit tests now?
(In reply to Philip Withnall from comment #1) > This is related to bug #782218, where the %LATEST_VERSION_RECORD atom was > removed from the priority string. I don't think it is; the problem is that the test tries to force SSLv3, so it will fail if SSLv3 isn't available. If something like g_tls_connection_get_connection_requirements() from bug 745637 landed then we could use that to test if SSLv3 was available and then skip the test if not. I guess I'd be OK with tweaking it for now so that if the SSLv3 test fails, it calls g_test_skip() rather than actually failing it. (But the TLS1.0 fallback test still needs to pass no matter what.)
Michael, it would be good to get this fixed for 2.56, since presumably more and more systems are going to be built without SSLv3 support as time goes on (since SSLv3 was prohibited in 2015).
(In reply to Dan Winship from comment #2) > I guess I'd be OK with tweaking it for now so that if the SSLv3 test fails, > it calls g_test_skip() rather than actually failing it. (But the TLS1.0 > fallback test still needs to pass no matter what.) Good idea.
Currently we run the test twice, with two different priorities: #define PRIORITY_SSL_FALLBACK "NORMAL:+VERS-SSL3.0" #define PRIORITY_TLS_FALLBACK "NORMAL:+VERS-TLS-ALL:-VERS-SSL3.0" PRIORITY_SSL_FALLBACK is guaranteed to be broken with newer GnuTLS, and PRIORITY_TLS_FALLBACK is effectively the default case, so neither is interesting. I think we should just not set custom priority strings for the test. That will avoid the problem entirely, and allow us to simplify the test by getting rid of the subprocess stuff. The priority strings are not supposed to be API anyway.
Created attachment 366327 [details] [review] Fallback tests should not expect SSLv3 to be available Dan, what do you think? This removes a bunch of code that you added to be able to test different priority strings, so I'm not sure if you'll agree with this approach....
Comment on attachment 366327 [details] [review] Fallback tests should not expect SSLv3 to be available If we're going to continue to support :use-ssl3, then we should have the code to test it (even if that test can't be run on some machines). But if that's going to go away then obviously the tests can too.
(In reply to Dan Winship from comment #7) > If we're going to continue to support :use-ssl3, then we should have the > code to test it (even if that test can't be run on some machines). Of course, "we can't test that the code still works" is also a good argument for not supporting it any more.
My point is that there's no point in running the test under a special priority string. All we care is that the property performs as documented. It's documented to force the connection to use the lowest-supported version of SSL/TLS. We can't check if that actually works until we implement bug #745637 (which is still on my TODO list, I promise ;) so the best we can do is check that the connection succeeds, same as the current tests do.
ah, I just saw that it was deleting a bunch of code and thought you were getting rid of the whole test. Yeah, this makes sense.
Nah, the test stays, but now it will run once instead of twice, and with the default priority string instead of with custom priority strings.
Attachment 366327 [details] pushed as 806d703 - Fallback tests should not expect SSLv3 to be available