On 27.01.2016 09:05, Anton Khirnov wrote: > Quoting Andreas Cadhalpun (2016-01-27 01:18:23) >> Could you explain in more detail what problem that would cause? >> The whitelist should simply be passed from http to tcp in that case. > > You have to go over all the (de)muxers that call the protocol layer > directly and all the protocols and ensure that those > restrictions are passed through correctly. That is a somewhat nontrivial > amount of work. Not to mention that we first have to design those > restrictions. That's also a not completely obvious step, especially if, > as you're suggesting below, they should somehow be format-dependent. > > Frankly, I don't have that much free time on my hands to do all that > quickly. Or do you volunteer?
Fortunately Michael already did that [1][2]. >> I think that applications wanting this behavior should explicitly enable >> it. To ease the transition period, one could set the protocol_whitelist >> to something sensible for this case, e.g. 'file,http,https,tcp', when the >> filename has the extension of a playlist. > > That implies the whitelist is format-dependent, which is already rather > nontrivial. Yes, that's unfortunately true. But one could e.g. append some protocols to the whitelist (and emit a warning that this is a potential security problem and will thus stop working unless the protocol_whitelist is set) in the hls demuxer if the url is http/https (and the whitelist the default for the file protocol), so that this use case would keep working for a transition period. >> Then just add quick hacks preventing the worst problems. >> I'd rather not have functionality hastily removed due to security >> concerns, that could be easily worked around until a proper solution >> is found. > > I don't really understand your position -- on one hand you don't want to > remove "useful" functionality, even though the concat protocol is IMO > borderline-useless. OTOH you are quite fine with breaking applications > by adding restrictive defaults. My main point is that removing the concat protocol is not a proper fix for this problem. Breaking use-cases is never good and should happen with a transition period. On 28.01.2016 10:26, Anton Khirnov wrote: > Quoting Andreas Cadhalpun (2016-01-27 01:15:07) >> I think that at the very least the hls demuxer should always reject protocols >> internal to libavformat, like concat, as those simply do not belong into a >> hls >> playlist. >> > > I find it rather strange how you're talking about solving the general > problem in a proper way, but here you say that specifically the hls > demuxer should behave in some special way. > > The general problem is not specific to hls, and can just as well happen > with any future playlist-based demuxer, so the solution should not be > hls-specific. Yes, but that there is a general problem doesn't mean that there is no problem in the hls demuxer. A 'concat:' line just doesn't make sense in a hls playlist and thus shouldn't be accepted by libavformat, as it also isn't accepted by other players. Best regards, Andreas 1: https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/188238.html 2: https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/188239.html _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
