1
0
mirror of https://github.com/mpv-player/mpv synced 2025-03-20 02:09:52 +00:00
mpv/DOCS/man
wm4 bb0650d908 loadfile, ytdl_hook: don't reject EDL-resolved URLs through playlist
The ytdl wrapper can resolve web links to playlists. This playlist is
passed as big memory:// blob, and will contain further quite normal web
links. When playback of one of these playlist entries starts, ytdl is
called again and will resolve the web link to a media URL again.

This didn't work if playlist entries resolved to EDL URLs. Playback was
rejected with a "potentially unsafe URL from playlist" error. This was
completely weird and unexpected: using the playlist entry directly on
the command line worked fine, and there isn't a reason why it should be
different for a playlist entry (both are resolved by the ytdl wrapper
anyway). Also, if the only EDL URL was added via audio-add or sub-add,
the URL was accessed successfully.

The reason this happened is because the playlist entries were marked as
STREAM_SAFE_ONLY, and edl:// is not marked as "safe". Playlist entries
passed via command line directly are not marked, so resolving them to
EDL worked.

Fix this by making the ytdl hook set load-unsafe-playlists while the
playlist is parsed. (After the playlist is parsed, and before the first
playlist entry is played, file-local options are reset again.) Further,
extend the load-unsafe-playlists option so that the playlist entries are
not marked while the playlist is loaded.

Since playlist entries are already verified, this should change nothing
about the actual security situation.

There are now 2 locations which check load_unsafe_playlists. The old one
is a bit redundant now. In theory, the playlist loading code might not
be the only code which sets these flags, so keeping the old code is
somewhat justified (and in any case it doesn't hurt to keep it).

In general, the security concept sucks (and always did). I can for
example not answer the question whether you can "break" this mechanism
with various combinations of archives, EDL files, playlists files,
compromised sites, and so on. You probably can, and I'm fully aware that
it's probably possible, so don't blame me.
2019-01-05 09:11:18 +01:00
..
af.rst f_lavfi: add an option to use old audio PTS handling for af_lavfi 2018-04-15 23:11:33 +03:00
ao.rst ao_pulse: reduce requested device buffer size 2018-04-15 23:11:33 +03:00
changes.rst manpage: mention the client API/interface change logs 2016-09-02 09:48:35 +02:00
encode.rst encode: remove old timestamp handling 2018-05-03 01:08:44 +03:00
input.rst demux, stream: readd cache-speed in some other form 2018-09-01 13:04:45 +02:00
ipc.rst json: add some non-standard extensions 2018-05-24 19:56:34 +02:00
javascript.rst js: implement mp.register_idle 2018-04-07 16:02:19 -07:00
libmpv.rst manpage: define stricter rules for C plugin return values 2017-01-14 17:41:04 +01:00
lua.rst lua: expose mpv_abort_async_command() 2018-05-24 19:56:34 +02:00
mpv.rst manpage: mention that fd:// file descriptors may be modified 2018-05-24 19:56:34 +02:00
options.rst loadfile, ytdl_hook: don't reject EDL-resolved URLs through playlist 2019-01-05 09:11:18 +01:00
osc.rst config: replace config dir lua-settings/ with dir script-opts/ 2018-04-07 16:02:16 -07:00
stats.rst config: replace config dir lua-settings/ with dir script-opts/ 2018-04-07 16:02:16 -07:00
vf.rst vf_vavpp: select best quality deinterlacing algorithm by default 2018-02-13 17:45:29 -08:00
vo.rst docs/vo: fixup some minor typos a la "planed" instead of "plane" 2018-05-01 20:49:30 +03:00