GNOME Bugzilla – Bug 691930
set_ssl_ca_file try unreffing a NULL GObject if TLS is not supported
Last modified: 2013-02-26 09:50:38 UTC
In soup-session.c : set_ssl_ca_file() we use /dev/null as fallback DB only if: if (!g_error_matches (error, G_TLS_ERROR, G_TLS_ERROR_UNAVAILABLE)) { So for any other error ('error TLS support is not available' in my jhbuild), we don't create any tlsdb but then still try to unref it once we have called set_tlsdb(), raising a warning. Any reason to not always use /dev/null as fallback if something went wrong?
(In reply to comment #0) > Any reason to not always use /dev/null as fallback if something went wrong? Hum actually that doesn't work as I still get this error. So we should just check if the tlsdb is not NULL before unreffing.
Created attachment 233655 [details] [review] set_ssl_ca_file: don't try unreffing tlsdb if it's NULL If g_tls_file_database_new() failed for any reason but G_TLS_ERROR_UNAVAILABLE, we don't create a fallback DB and so tlsdb stays NULL.
Comment on attachment 233655 [details] [review] set_ssl_ca_file: don't try unreffing tlsdb if it's NULL (In reply to comment #1) > (In reply to comment #0) > > Any reason to not always use /dev/null as fallback if something went wrong? > > Hum actually that doesn't work as I still get this error. right, g_tls_file_database_new() will return NULL (with another G_TLS_ERROR_UNAVAILABLE) if you have the fallback TLS backend. so the only-unref-if-not-NULL patch is correct. thanks.
Attachment 233655 [details] pushed as 91f1eea - set_ssl_ca_file: don't try unreffing tlsdb if it's NULL
*** Bug 694729 has been marked as a duplicate of this bug. ***