On Tue, 6 Jun 2017, Michael Niedermayer wrote:
On Mon, Jun 05, 2017 at 05:33:29PM +0200, Nicolas George wrote:
Le septidi 17 prairial, an CCXXV, Michael Niedermayer a écrit :
[...]
You dont need to convince me that the extension check or changes
within just hls are not a complete solution. Iam quite well aware
of this. This is intended to stop an existing exploit and variants of
it in practice and do so quickly.
It depends on the severity of the threat. This one seems quite minor and
far-fetched, and thus I think we could take our time to fix it properly.
We all have noticed that temporary quick-and-dirty fixes usually stay
here a long time unless whoever implemented them is actively working on
a real fix.
I disagree that the issue is minor and far fetched.
Do we really want to impelment a whole security framework inside an AV
library? Can't we decouple this from libav*? E.g. let the user implement
his security framework via callbacks or something?
We can provide a good enough reference implementation for the command line
tools (outside the libraries), so things won't break too much, but if you
ask me, by default, all reference openings should be disabled, that is the
only truly secure thing, anything else can be insecure based on your use
case.
Regards,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
