Ricardo Wurmus <rek...@elephly.net> writes:
> Ricardo Wurmus <rek...@elephly.net> writes:
>
>> Pierre Neidhardt <m...@ambrevar.xyz> writes:
>>
>>> With Epiphany: […]
>>> 0:00:02.444056430 6908 0xdc3320 WARN curlhttpsrc
>>> gstcurlhttpsrc.c:1068:gst_curl_http_src_handle_response:<curlhttpsrc0> Curl
>>> failed the transfer (60): SSL peer certificate or SSH remote key was not OK
>>
>> That’s the same error I got. It may be worth checking if we can patch
>> gstcurlhttpsrc.c to ensure that the path of the certificate bundle is
>> set via environment variable.
>>
>> A hack to check that this is indeed the cause might be to place the cert
>> bundle in the expected default location that libcurl uses when the
>> client does not specify a location.
>
> Here’s a little patch to confirm that indeed this problem is caused by
> gstcurlhttpsrc.c (of gst-plugins-bad) not configuring libcurl to look
> for certificates in the right place: […]
I should note that gstcurlhttpsrc.c has a mechanism to set the location
of the ca-certificates.crt file:
--8<---------------cut here---------------start------------->8---
g_object_class_install_property (gobject_class, PROP_SSL_CA_FILE,
g_param_spec_string ("ssl-ca-file", "SSL CA File",
"Location of an SSL CA file to use for checking SSL certificates",
GSTCURL_HANDLE_DEFAULT_CURLOPT_CAINFO,
G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS));
--8<---------------cut here---------------end--------------->8---
I just don’t know how we could possibly provide a value for this
property as we don’t call the plugin on the command line. It would be
nicer, of course, if we could use this mechanism instead of using a
patch similar to what I showed in my previous email.
--
Ricardo
