On Fri, 23 Feb 2018 01:21:52 +0100 Michael Niedermayer <mich...@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 <mich...@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 <mich...@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 <mich...@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 <mich...@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 <jamr...@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". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
