[Development] Another method of registering QML types
Alan Alpert
416365416c at gmail.com
Fri Nov 9 00:56:42 CET 2012
On Thu, Nov 8, 2012 at 2:15 PM, Richard Moore <rich at kde.org> wrote:
> On 8 November 2012 21:17, Alan Alpert <416365416c at gmail.com> wrote:
>> On Thu, Nov 8, 2012 at 12:49 PM, BRM <bm_witness at yahoo.com> wrote:
>>>> From: Alan Alpert <416365416c at gmail.com>
>> If you have a http://remote/Image.qml with code like Image { source:
>> "graphic.png" } the png will be fetched transparently.
>>
>>> [1] Yes, I realize that it would enable some on-the-fly stuff that might generate some security concerns. I would suggest that be documented so that users know they have to load appropriately trusted materials if we did that. They could just as easily write it to a temp file and load the temp file using the regular API too.
>>
>> That is the current alternative. You can do the exact same thing by
>> writing out a temporary qmldir file to disk - it's just that I think
>> that approach is horrible and unnecessary. (This is actually more of a
>> security risk, because you could be overwriting the qmldir files for
>> other imports, like "." ).
>
> Loading code on the fly from a remote location like this without
> enforcing HTTPS etc. is just plain crazy. I'd strongly suggest that it
> be disabled by default if that's actually possible now.
The QML security policy is to be as careful with executing remote QML
as you would be with remote binaries. I agree it's usually crazy to do
that without enforcing some measure of transit security, but like C++
we leave that to the user. This prevents it from ruling out the cases
where it's not crazy, like when it goes through trusted networks (like
internal apps) or is properly sandboxed (like web apps).
--
Alan Alpert
More information about the Development
mailing list