[FFmpeg-devel] [PATCH] add av_enable_strict_whitelists()

wm4 nfxjfg at googlemail.com
Sun Oct 26 02:09:19 CEST 2014


On Sun, 26 Oct 2014 00:16:26 +0200
Nicolas George <george at nsup.org> wrote:

> Le quartidi 4 brumaire, an CCXXIII, Michael Niedermayer a écrit :
> > This fixes the issue that a not set or not forwarded whitelist
> > would allow to bypass it.
> 
> I am a bit worried by the sheer amount of extra code and API this simple
> feature requires. Maybe it is a sign that it was not the best approach to
> begin with.
> 
> Also, I did not say at the time, but I believe using a string to hold a list
> like that is quite ugly.
> 
> Unless I am mistaken, the core of the problem resides in the existence of
> global variables in the library, and this is not the only instance of this
> issue: remember people who want to free the global mutex manager, not
> understanding that "still reachable" is not a memory leak.
> 
> There is an idea that I have been nursing for some time: moving all these
> global variables to a structure, and start passing it around everywhere.
> Most of the functions that access the global variables already have some
> kind of context where the pointer can be stored, so it would only require
> changing a few API entry points.
> 
> That may look somewhat like that:
> 
> AVCodecInstance *libavcodec = avcodec_library_create(OPTIONS);
> AVFormatInstance *libavformat = avformat_library_create(libavformat, OPTIONS);
> 
> avformat_instance_open_input(libavformat, &ctx, filename, NULL, NULL);
> 
> Then the whitelist feature comes for free: use the options to disable
> registering all the codecs, then manually register the ones needed.
> 
> Of course, for compatibility, a global instance need to be inited if the
> legacy entry points are used, but it becomes much easier to test extensively
> that modern API usage will not touch them.
> 
> Of course, that requires more work, and the whitelist feature will not be
> available immediately, but in the long run I believe it would be greatly
> beneficial.
> 
> What do people think of that?

That's exactly the same idea I suggested some hours ago on IRC - so
it's not good, I guess?


More information about the ffmpeg-devel mailing list