[texworks] Scripting read access

[Paul A Norman]

Hi,

I am itching to use Python myself but have limited myself so far to
QtScript as I am aware that  the ginormous number of people who have
had to be hands on with JavaScript (through their web pages - whether
they wanted to or not) are going to flow into QtScript more easily
than Lua or Python - at least initially.

Regarding security I really do appreciate what is trying to be
achieved here, at one level at least, but...

I've been looking at it more form the point of view of the user who
wants some particular functionality provided by scripts, and doesn't
know, or want to know, the difference between Lua, Python, or
QtScript.

All they want is that extra functionality provided in TeXworks - and
to get on with their writing project(s).

They may not even really know what a 'script' is - and just be
following some procedures/instructions to get the functionality, that
they want, working.

I still feel that emphasizing inspection, and the provenance of
scripts, is the best protection people have -

 where did they get the script from?
 do they have reason to trust the script writer?
 Have they read though it?
 does it use the system or  writeFile etc  words
  - what does it use such words to do?

Perhaps these things could be emphasised or a link to the html help
with that info in it could be placed in the Script Manager?

Even a non-scripter could spot such words, and if they didn't look
'right in their use'  ask a question on a forum first - and perhaps be
introduced to scripting through the process.

Otherwise in a sense, what is a user deciding when they simply turn on:
  allow scripts to read files,
  allow scripts to write files,
  allow system commands,
or use powerful script plugins.

What is the average Tw user actually, in reality, basing these decisions on?

They will, I suggest, mostly be turning them on because they want some
functionality that a specific new script provides, and the script
writer's read-me file said turn it on to make the script work.

That's all.

I'm afraid that is how the vast majority of computer users have been
found to operate - not the developers, or technically savy computer
users, but people who just want to use their computer to get a writing
job or a graphics job done, the kinds of new users we want TeXworks to
attract to LaTeX - people who want a simpler interface - also want a
straight forward experience.

So to get their new 'module' or script (or however they think of it)
to work - now the safety switch(es) are off only because the script
writer told then to turn the off, and that particular script now works
- but so now can anything else that uses those settings!

Have any safety considerations  actually been made by the average Tw User?

Is this a real safety decision, or some kind of reckless expediency
based upon an individual script's requirements?

Here I am assuming that scripts get into the Tw/config/scripts folder
because the user is placing them there.  If we imagine that rogue
scripts are going to find their way to that folder in a malicious
manner, then what safety or purpose is there in ever ticking the
security relax tick boxes?

Thinking about it in those terms led me to think that we were perhaps
being developer centric in the security issues - and that in its
present form and genesis, some of it will make no, or little, sense at
all to many of the kind of new TeXworks users we want to attract into
using LaTeX.

That's why I gravitated into thinking about some sort of Master
Switch, and be done with it.

Paul

On 6 December 2010 01:48, Stefan Löffler <st.loeffler at gmail.com> wrote:
> Hi,
>
> On 2010-12-04 23:16, Paul A Norman wrote:
>> I have been using the fileOpen functions to open all sub documents
>> when using a master document, there's been a script up on your script
>> Issues page for quite a few months now.
>
> Now you mention it, yeah, I remember dimly ;).
>
>> Its sort of useful especially when you need to search through all
>> documents - they all need to be open before the search starts. Or when
>> you  just want to position the cursor and open a sub document. (Select
>> between braces, get selected text, construct full path, open document)
>>
>> If the user has  allowed scripts to read documents from disk - could
>> we make these script functions for actually opening Tw documents work
>> on the same User's check box preference selection? Perhaps
>> automatically allowing same target and script and sub directories as
>> for the readFile function itself?
>>
>> There would be other times when it is very useful to be able to open
>> Tw document(s) from script for user editing.
>>
>> Be sad to loose this functionality.
>
> OK, in r709, I've reinstated a method named openFileFromScript. Typical
> usage would be:
> res = TW.app.openFileFromScript("/path/to/file.tex", TW, -1, true);
>
> The behavior is very similar to readFile, w.r.t. the handling of
> relative paths and required permissions. res also is similar to the
> return value of readFile, only res.result is now the object of the
> opened window (if any). The second parameter (TW) is required to give
> the function the proper context. The last two arguments are optional. -1
> is the line number (the default -1 stands for the start of the file),
> and true is whether or not to ask the user for permission to open the
> file in case the "normal" permissions are insufficient.
>
>> Or allow ALL things of this perceived security issue nature to be
>> doable if  "use script plugins" is ticked by the User, as after all
>> the script plugins automatically open the Pandora's box of security
>> issues wide open any way don't they?
>
> Well, there are several connections between the different security
> settings. E.g., with execution enabled, you can possibly read and write
> files with `cat path/to/file` or `echo "Content" > path/to/file`. Also,
> as you say, plugins may bypass these protected functions of Tw
> altogether. Nevertheless, I don't think this should be encouraged.
>
>> It would seem counter intuitive that read or write scripts be turned
>> off, and script plugins be
>> turned on letting python and Lua then do things that QtScript can then
>> not do - seems confusing?
>
> Well, the read, write, execute permissions naturally only apply to Tw.
> What a scripting plugin may or may not do in addition, and how it
> enforces any of these restrictions, is up to the plugin. That's why
> plugins are powerful, but dangerous, and are hence disabled by default.
> Note, though, that I haven't heard many accounts of non-QtScript scripts
> lately... so the question is how much the "enable plugins" option will
> be used at all.
>
> HTH
> Stefan
>