[texworks] Script: Questions about the API

[T T]

On 14 April 2010 18:22, Stefan Löffler <st.loeffler at gmail.com> wrote:
> Hi,
>
> Am 2010-04-13 15:49, schrieb T T:
>> On 13 April 2010 07:06, Stefan Löffler <st.loeffler at gmail.com> wrote:
>>
>>> If you can write arbitrary data to arbitrary positions on the
>>> disk, this can be pretty serious security vulnerability.
>>>
>> Why?  The extension script will not get more permissions than the
>> program (process) in which it runs and I see no reason why it should
>> have less permissions.  After all, extension scripts are logically a
>> part of an application and not a part of a document as in case of,
>> say, html and browsers.
>>
>
> You imply a (working) system of permissions. As Paul pointed out, this
> is not necessarily guaranteed all the time (in particular Windows users
> tend to abuse some functions).

I actually work on Windows, so I know that all too well.

> Now of course you can argue that that's
> their own fault, but since Tw is targeting all audiences, in particular
> people who are not PC pros, I am a bit reluctant to provide additional
> functions that can potentially cause a lot of chaos.

No, you misconstrued my argument.  I don't downplay the importance of
keeping things secure (I'm actually personally involved in making some
parts of TeX Live more secure), I only oppose unduly restrictions that
bring no tangible increase of security.  If someone is willing to
install and execute a program or plugin from an unknown/untrusted
source (no matter script or binary), there is no way to keep such a
person secure regardless of what you do.  But you can only hurt
legitimate use cases while trying.

> That said, we don't limit any of the functions of the respective
> scripting languages.

I'm glad to hear that and there is nothing more that I ask.

> Besides, providing general purpose file access functions wouldn't be as
> easy as it sounds. We could of course provide a QFile object wrapper,
> but I think that most methods in there are not exposed to scripting. So
> we'd end up with the need to write our own classes for that, which I
> think is more effort than it's worth at the moment (seeing that there
> are alternatives).

That is a valid technical argument that I fully understand.  Are Lua
extensions (going to be) still supported, or was this support dropped
in favour of QtScript (Lua comes with all this basic functionality
like file access out of the box)?

All the best,

Tomek