Le duodi 2 pluviôse, an CCXXIV, Andreas Cadhalpun a écrit : > I think introducing protocol_whitelist could be a general solution. > It could have sensible defaults, e.g. if it is not passed as option > to avio_open2/ffurl_connect it could default to only local protocols > unless the protocol to open is a network protocol, in which case > it could default to only network protocols. > > So when opening 'file:', 'concat:' or other local protocol, the > protocol_whitelist would default to local protocols. > When opening 'http:', 'https:' or other network protocols, the > protocol_whitelist would default to network protocols. > > That should prevent mixing of local and remote data, unless > specifically requested by the API/CLI user. > > So if e.g. a local playlist 'file:' would contain 'http:' URLs a > protocol_whitelist allowing this combination would be required > for playback.
You have the right idea, but a simple white list of protocols is not enough. If http://example.com/mostly_harmless.m3u pointing to file:///home/me/sensitive/file is a problem, then we have exactly the same problem with it pointing http://intranet.local/sensitive/file, even more so if protocol options can turn it into a POST request. If we want to take this issue seriously, we need a rather complex mechanism to ensure information separation, including same-origin policy and such. Removing or disabling the concat protocol is like double-locking the door when the window is still wide open. Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
