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

wm4 nfxjfg at googlemail.com
Fri Feb 23 11:09:34 EET 2018


On Fri, 23 Feb 2018 01:21:52 +0100
Michael Niedermayer <michael at niedermayer.cc> wrote:

> On Thu, Feb 22, 2018 at 07:31:27PM +0100, wm4 wrote:
> > On Thu, 22 Feb 2018 16:28:56 +0100
> > Michael Niedermayer <michael at niedermayer.cc> wrote:
> >   
> > > On Wed, Feb 21, 2018 at 09:02:40PM +0100, wm4 wrote:  
> > > > On Wed, 21 Feb 2018 19:14:59 +0100
> > > > Michael Niedermayer <michael at niedermayer.cc> wrote:
> > > >     
> > > > > On Wed, Feb 21, 2018 at 09:27:02AM +0100, wm4 wrote:    
> > > > > > On Tue, 20 Feb 2018 21:45:12 +0100
> > > > > > Michael Niedermayer <michael at niedermayer.cc> wrote:
> > > > > >       
> > > > > > > On Tue, Feb 20, 2018 at 06:28:20PM +0100, wm4 wrote:      
> > > > > > > > On Tue, 20 Feb 2018 17:30:32 +0100
> > > > > > > > Michael Niedermayer <michael at niedermayer.cc> wrote:
> > > > > > > >         
> > > > > > > > > On Tue, Feb 20, 2018 at 10:17:02AM -0300, James Almer wrote:        
> > > > > > > > > > On 2/20/2018 9:21 AM, wm4 wrote:          
> > > > > > > > > > > On Tue, 20 Feb 2018 08:47:51 -0300
> > > > > > > > > > > James Almer <jamrial at gmail.com> wrote:      
> > > > > [...]    
> > > > > > > > And for the 100th time: the new API is completely orthogonal to
> > > > > > > > allowing user-registered components. Since nobody could actually use
> > > > > > > > the API before, it's no problem to drop the old APIs now, and to add
> > > > > > > > actually working API once the other, much much much bigger problems are
> > > > > > > > solved.
> > > > > > > > 
> > > > > > > > Even if you argue that keeping the linked list is absolutely necessary,
> > > > > > > > the new API could support a linked list too.
> > > > > > > >         
> > > > > > > > > is it the ff_* symbols you are thinking of ?        
> > > > > > > > 
> > > > > > > > ff_ symbols are private.
> > > > > > > >         
> > > > > > > > > This is a problem for an existing API it is not a problem for a new API as
> > > > > > > > > we can change the symbols if they are intended to be used for individual
> > > > > > > > > component registration.
> > > > > > > > > The whole discussion is about designing a new API. So any limitation of
> > > > > > > > > an existing API can be changed.
> > > > > > > > > 
> > > > > > > > > There also should be no need to call register_all in the existing API,
> > > > > > > > > and there cannot be such a problem in a new design because it would be
> > > > > > > > > a new design you wouldnt design it to "not work".        
> > > > > > > > 
> > > > > > > > You're just being contradictory all across the board here. In other
> > > > > > > > places you're claiming this register mechanism is needed for
> > > > > > > > security or to make it possible to eliminate unused components when
> > > > > > > > static linking. But if all components are already registered without
> > > > > > > > doing anything, how is that supposed to work?        
> > > > > > > 
> > > > > > > If an application wants to register all, it calls the register_all()
> > > > > > > function
> > > > > > > If an application wants to register a subset it registers just that
> > > > > > > subset and does not call register_all      
> > > > > > 
> > > > > > But you just said on your mail "There also should be no need to call
> > > > > > register_all in the existing API,". How is that supposed to mesh with 
> > > > > > "If an application wants to register a subset it registers just that
> > > > > > subset and does not call register_all".      
> > > > > 
> > > > > I see no contradiction between what you quote, if that is what you meant:
> > > > > "There also should be no need to call register_all in the existing API,"
> > > > > and
> > > > > "If an application wants to register a subset it registers just that subset and does not call register_all"    
> > > > 
> > > > If there's no contradiction, it implies that either the first register
> > > > call will implicitly unregister all "automatically" registered
> > > > components, or the code has to explicitly unregister components. but in
> > > > both cases this would still require linking all components even if you
> > > > use static linking.
> > > > 
> > > > So you have the following possibilities:
> > > > - register_all needs to be called
> > > >   - contradicts your claim it doesn't need to be called    
> > >   
> > > > - register_all needs not to be called
> > > >   - all components are already registered implicitly    
> > > 
> > > why would not calling register_all(), register all components implicitly ?  
> > 
> > So what did you mean by "There also should be no need to call
> > register_all in the existing API,"?  
> 
> That as documented the user app should be able to register individual 
> components OR to call register_all().
> As register_all() is only required if the user application does not
> register components individually, it is not needed to call register_all()
> 
> We somehow seem to misunderstand each other here over several mails, iam
> not sure why. This is not complex or convoluted 
> 
> 
> [...]
> > > A library cannot register more components after that and if it somehow
> > > managed to register a component before that is detected by the user
> > > application which then exits with an error message explaining the user
> > > that the security model is not compatible with a library loaded.
> > > And that the user either has to add the specific listed components to
> > > the components the application registers or to disable secure mode or
> > > to do something about the library that registered the component.
> > > 
> > > This incompatibility may seem a problem but this is exactly what the
> > > intend of this security layer is. To NEVER allow ANY code in a
> > > process to use a component except the ones the application listed as
> > > allowed.  
> > 
> > I don't think that works. If there are "unknown" libavcodec uses in the
> > process that could take untrusted input data you've probably already
> > lost.  
> 
> Yes.

Good.

> 
> > On the other hand, you can set whitelists on any AVFormatContext
> > or whatever, because you control it.  
> 
> Yes, absolutely. Thats the case that i used as comparission to initially
> explain why the disabling with not registering unwanted components is more
> robust.
> 
> To recap, its more robust to additionally globally disable things once vs 
> having maybe a thousand lines of code inside our libs and hundreads in more complex 
> user apps to ensure every component gets the right whitelist and its always
> enforced.

In that setting you've already lost too.

So what does this have to do with changing filters to the new API?
Because there isn't a security argument with filters (even if I'd
accept that security of yours).

Regarding the security argument, I don't agree that an intrusive
mechanism that "sort of" in theory _could_ help with it is a good idea.
You could could just argue for about anything with this argument, as
long as you can construct a security advantage. And then blame anyone
who disagrees with "not caring about security".


More information about the ffmpeg-devel mailing list