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). It would also require the calling programs to have quite a lot of knowledge about the libav protocol layer internals. I think Rémi also had other objections, on which he'll hopefully elaborate himself. > > > 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, so making this behaviour forbidden by default is likely to break many applications. 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. 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. -- Anton Khirnov _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
