[FFmpeg-devel] [PATCH 0/3] Finish new iteration APIs

[wm4]

On Tue, 20 Feb 2018 08:47:51 -0300
James Almer <jamrial at gmail.com> wrote:

> > It has fully achieved its objectives. There's no more visible global
> > mutable state, and the actual global mutable state has been reduced to
> > less than 5 codec entries.  
> 
> It's true that after the deprecation period they will effectively be the
> only ones still mutable, but shouldn't the objective be to cover them all?

That would be nice. But this has been discussed before. No kind of
different registration API could fix this issue either, unless we start
mallocing AVCodec structs and require the user to free them, or
something equally absurd. The proper solution for this specific issue
would be making a new API that somehow replaces AVCodec.pix_fmts.

> > 
> > Why are we discussing this _again_?  
> 
> Because a drawback has been found, namely that link time optimization
> using static libraries can't remove "non registered" modules anymore,
> and now depends fully on what's enabled at configure time.
> Ideally, a better registration based API that follows what i described
> above should be designed with care.

Oh yeah, bikeshed attack by Michael. As it was said a few thousand times
already, public API users could NOT use the registration stuff to
register only specific components at runtime. So they have to use the
register_all variants, which pull in _all_ components even with static
linking.

And that can't be made with dynamic linking either. If you statically
link anyway, you probably control everything, and you can configure this
stuff at compile time.

Then I guess there's this very special case where a fuzzer statically
links to libavcodec, and registers only a few components (technically
violating the API and by guessing the component symbol name), and
without calling the register_all functions. This would make the
resulting executable much smaller, which is apparently important
because Google (who runs the fuzzers for their oss-fuzz project) is too
poor (?) to host all the statically linked fuzzers, _or_ the whitelist
stuff is not enough to trick the fuzzer into not trying to fuzz the
wrong code. In addition, it's apparently infeasible to just build
every fuzzer with a separate libavcodec. (Not sure about the details, it
was something like this.)

Those requirements are really quite nebulous. I don't know why we even
should care - surely whoever does this will find a solution that works
for them. For example they could apply a small patch that makes the
codec_list[] symbol non-static non-const, which would allow them to
overwrite it (i.e. deleting unneeded entries). It's a really simple
solution that took me 5 minutes to come up with.

The security argument is absurd, because you'd just disable them at
compile time, and if you really want to restrict components at compile
time, there's this whitelist stuff for codecs and a few other things.

I feel like I've written this post 3 trillion times, and Michael never
read any of them.

> >   
> >> Whatever is done, in any case, should be decided fast. The current new
> >> API is in the tree and should be removed without delay if we decide to
> >> not use it in the end, even if a proper replacement is not written in
> >> the short term.  
> > 
> > What needs to be done is testing and applying these patches.  
> 
> What makes me uneasy is that if this API remains is place, introducing a
> new better one would be annoying for downstream users if it's added too
> close to the end of the old API's deprecation period, be it before or
> after. Having to migrate a second time in a short time frame is undesirable.
> 
> In any case, just my two cents. Don't take this as a blocker for this
> set, but as a request to consider better alternatives in the short or
> long term.

Like what? What color is it going to be?