options: enable tls-verify by default #17909
Conversation
stream-lavf-o[cookies] only feeds the lavf stream backend. Instead of side-loading it, use core `--cookies-file` option.
Will be useful for future commits
Introduces stream_http, an internal libcurl-driven backend for http:// and https:// URLs. Runs all transfers on a dedicated curl multi thread with a producer-side ring buffer, and exposes HTTP/2 multiplexing, QUIC/HTTP/3 (when libcurl supports it), HSTS and TCP keep-alive. Should generally be more stable and faster than FFmpeg HTTP/1.1 impl, additionally connections are kept-alive between files open, so if you open playlist of network files and navigate through them, it will re-use the same connection. Build is gated on the new 'libcurl' meson option (auto). When disabled or unavailable, mpv silently falls back to FFmpeg's HTTP implementation.
Hook AVFormatContext.io_open so HLS/DASH segment fetches and other nested FFmpeg I/O go through stream_http when libcurl is available. This lets segments inherit the connection reuse, HTTP/2 multiplexing, mid-stream resume and conditional compression of the top-level stream. Falls back to FFmpeg's default I/O for non-HTTP URLs and when the curl backend is not built in.
Allow only subset of supported protocols by libcurl.
This is for stream_curl.
At the initial file open, the buffer may be populated with more data, than later requested by decoder, but don't drop this data. This fixes initial open to perform multiple reads of the area, especially for images that are likelly fully read for probbing already.
It's significantly more stable than Lavf. Fixes seeking out of cached ranges. Additionally correctly marks demuxer_is_network for ftp too.
|
Can you limit this to curl backend only? ffmpeg does not sensibly try to search for system CA store, so in practice nothing works unless manually specifying CA file. |
This depends on the TLS backend. schannel clearly will use CA store, while for openssl, on Linux, distributions usually handle it. By the way, Windows CI builds all use schannel, and although zhongfly builds use openssl, it has been patched to use CA store by default.
There is no difference. When curl is built with schannel backend, CA store is used by default, whereas built with openssl backend, CA store is not used unless curl is built with CURL_CA_NATIVE=ON. |
I posted this more as a RFC, because I'm aware some broken systems may have issues with this. However, https is prevalent and having broken CA store or not usable is rather user error at this point in time. FYI, I was recently testing all things with this option enabled, which also affects ffmpeg, and it works fine, but I indeed use schannel on Windows. We could set explicit CA to ffmpeg if curl is linked in, to the same file. There are still issues that we use http.c from lavf in some cases, because of https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/23071. All in all, I would prefer to have it enabled, even if it cause breakage. I know it sucks, but user can mitigate it, by updating their settings. Also some remaining issues may be resolved on the packaging side. |
|
Note that FFmpeg will enable TLS verification on next major version bump. FFmpeg/FFmpeg@5621eee And version bump is coming with big steps https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/22455 |
This affects all linux systems out of box. Certificate package is already installed. But CA search still needs to be handled by curl or tls library.
This is where the issue is. mpv should let curl search for CA store for openssl backend, and only enables tls verify be default if this can be done.
This is only done after FFmpeg/FFmpeg@080dc4c which lets it search for CA so tls verify works by default. The option should not be enabled by default on older versions. |
So it's package issue of libcurl, not ours.
I don't think this is valid. This breaks expectation that TLS is verified. We do verify when we feel like it? It should be the conscious decision of the user to either disable verification or fix CA.
Sure, I will gate it with the same api level. |
curl can search for native CA store with
This is similar to the ffmpeg situation. If curl can attempt to perform CA search then tls verify should be enabled by default. If it is not supported then it should be disabled. |
I can enable |
|
Updated, now it enabled by default only when libcurl is used or for lavf > 63 |
|
It would be best to log a warning when tls-verify cannot be enabled by default. |
|
It's build time check, not sure it's worth logging that. Eventually it will go away as mpv migrates to libcurl and ffmpeg itself is updated. In the meantime it remains as it were, disabled. |
This is independent of other CA certificate locations set at run time or build time. Those locations are searched in addition to the native CA store.
We shouldn't default to no verification in current year. User can opt-out if needed. Keep it disable for builds without libcurl when libavformat is older than 63.0.100. This is done to match ffmpeg's timeline for enabling tls_verify by default in lavf, also to ensure we the default verify locations will be loaded on such version.
4 participants
No description provided.