> From: Alan Alpert <[email protected]> >Sent: Tuesday, December 11, 2012 2:46 PM >Subject: Re: [Development] Controlling QML Imports > >On Tue, Dec 11, 2012 at 7:52 AM, Thiago Macieira <[email protected]> wrote: >> On terça-feira, 11 de dezembro de 2012 15.44.37, Aaron J. Seigo wrote: >>> > > > loading of native plugins from the application? >>> >>> Yes, but not native plugins installed by the QML applications. In such a >>> situation we need to be able to ensure that applications which say "I will >>> access this list of plugins" only do so. >>> >>> Is this realistic? It is precisely what we've been doing for a number of >>> years in Plasma. >>> >>> > > I tend to agree with Thiago. How does restricting this help for native >>> > > apps? It's anyway the app itself setting the restrictions. >>> >>> Well, yes, it doesn't help for "native" apps. That's not the point, is it? >>> Because some kinds of applications will not benefit from this does not mean >>> that those which would should not have a facility to use to accomplish it. >> >> It seemed to me that it was as well. >> >> I'm not doubting the benefit of this for controlling what a plugin in QML >> does. >> I was just questioning the use of this feature to enforce device and platform >> security. It's the wrong level. > >Correct, this is not a complete device and platform solution. The idea >though is that this could be used when implementing a complete device >and platform solution, because that complete solution on a lower level >may need to have an answer for QML too. If your runtime runs qml >directly you may want to restrict its ability to call native code >(because everything QML does is exposed native code). Here are a >couple of examples to clarify when this might be used: > >A) Creating a mobile platform that can have native executables >deployed to it. Here you need a lower level security control anyways, >you probably won't use this. >B) Creating a mobile platform that is locked-down and does not allow >3rd party executables. All 3rd party applications must be QML files. >Here you might be able to use import control to prevent loading of 3rd >party executables entirely. >C) Creating an application platform that accepts QML scripting for >part of the UI or data. QML is a great language for your usecase, but >you only want 3rd party scripts to render graphics within their little >box and call application specific functionality. You do not want it to >create new windows, you do not want it to have access to the command >line arguments, and you do not want to let it draw particles (because >that would really show up your UI ;) ). In this case this kind of API >would be exactly what you need in order to have a powerful embedded >scripting engine without endangering your app. >
"C" seems to be the KDE Plasma/Plasma Active use-case. That said...would it seem beneficial for a three part system: a) the QML security model b) the native security model c) a platform-integration component that works with the underlying system for implementing 'a' and 'b'. Now, I'm not saying anything about scope of this for Qt5 - it would seem to be a pretty big scope and likely with very deep implications in the implementation and compatibility requirements. $0.02 Ben _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
