# [tex-live] ConTeXt in TL on Windows broken

Wed Jun 2 15:58:15 CEST 2010

On 2 June 2010 11:44, Mojca Miklavec <mojca.miklavec.lists at gmail.com> wrote:
> On Tue, Jun 1, 2010 at 21:18, T T wrote:
>> On 1 June 2010 17:49, Mojca Miklavec wrote:
>>> On Tue, Jun 1, 2010 at 18:30, T T wrote:
>>
>> I didn't thought that this "%PATH" was meant literally.  In that case
>> there is something really wrong with the installer.
>
> Yes, it was meant literally. But I have never said that TL installer
> has set that path :) :) :)

Indeed, it is me, who assumed TL installer.

> (There is some weird thing going on that I still don't understand, but
> is not related to TL. When I open a new cmd, it sometimes holds TL
> binaries in PATH and sometimes not, so I sometimes have to set the
> path manually. But I won't spend any time trying to figure out why
> that happens since it might be any component of software that's
> interfering. I'm using a virtual machine with single windows and some

Duuno if that's the reason but after you change something in the
change. Otherwise the new settings might not take effect until the
next reboot (or until something else posts that message).

> No, I mean this one:
>    http://minimals.contextgarden.net/setup/context-installer/
> (but I need to check why the date of file is so old.)

> I'm not sure about the current state of luatex, but last time we tried
> it was no problem to put a statement
>    os.execute('rm -rf something')
> inside a TeX document. And Reinhard might also be right about
> security.

At least on windows this requires enabling write18:

[H:\DEV\temp\]
$luatex \directlua{os.execute('echo PASSED')}\end This is LuaTeX, Version beta-0.40.6-2009110118 (Web2C 2009) No pages of output. Transcript written on texput.log. [H:\DEV\temp\]$ luatex  --shell-escape \directlua{os.execute('echo PASSED')}\end
This is LuaTeX, Version beta-0.40.6-2009110118 (Web2C 2009)
\write18 enabled.
PASSED
No pages of output.
Transcript written on texput.log.

If this is not the case on unix, we need to fix it urgently.

> In my view it is OK to first search in path and then in
> current directory, but searching in current directory at all and in
> "path that is a bit wrong, but still works for windows" might still
> make sense.

I disagree, sorry.  Triggering processing through some utility that
might not be installed (and thus not on the path) would lead to
execution of (potentially malicious) stuff from the current dir.
People wanting the current dir always present on the path can add it
there but making this default for everybody is not a good idea, IMO.

Cheers,

Tomek

PS. In case you're still unconvinced that this sort of threats should
be taken seriously:
http://cseweb.ucsd.edu/~hovav/papers/csr10.html