[Development] Controlling QML Imports

[BRM]

> From: Alan Alpert <416365416c at gmail.com>

>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 <thiago at kde.org> 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