On 26.01.2016 19:42, Anton Khirnov wrote: > Quoting Andreas Cadhalpun (2016-01-26 01:02:04) >> On 22.01.2016 13:37, Anton Khirnov wrote: >>> Just so it's clear what we're talking about, what is "properly" for you? >> >> That would be a more or less general mechanism, which would have prevented >> the information leak in the hls demuxer by default. It should also prevent >> any such possible problems in other demuxers. >> This could be done by implementing a protocol_whitelist with sensible >> defaults. > > That was my first idea as well. Turns out, it's rather nontrivial to > implement, due to the fact that protocols allow nesting (e.g. http over > tcp).
Could you explain in more detail what problem that would cause? The whitelist should simply be passed from http to tcp in that case. > It would also require the calling programs to have quite a lot of > knowledge about the libav protocol layer internals. Most programs should be able to work with the default. >>> And what do you see as "the underlying problem"? >> >> I think that is libavformat mixing local and remote data. If it wouldn't >> to do that by default, such information leaks shouldn't be possible. >> > > Opening a local playlist that references remote streams is quite common, Though it is a lot less common than simply opening a local file. > so making this behaviour forbidden by default is likely to break many > applications. 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. > So while I fully agree that the concat protocol is not the root problem, > it is the source of its most significat symptom and removing it will > prevent the worst leaks. That could also be done by disabling it by default, i.e. unless an option to enable it is given. That way people using it could at least continue to do so after setting said option. > Meanwhile, we will have time to introduce the > infrastructure to fix this properly (which I think I already started, > but finishing it is, as said above, nontrivial). > And I'd really rather not design new APIs at gunpoint from pressing > security bugs. 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. Best regards, Andreas _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
