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

[Michael Niedermayer]

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.


> 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.

Thanks

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180223/28415722/attachment.sig>