Dear all!

THe packages of ConTeXt I am currently preparing are tested by a user and he send back the following questions/comments. Could you please comment on this.

For the background: I install all the stubs from scripts/context/stubs/unix into /usr/bin, add a texmfstart stub that calls ruby with the right path to texmfstart.rb.

----- Forwarded message from Mike Bird -----

...

From: Mike Bird Subject: New texexec very confused To: debian-tex-maint@lists.debian.org Date: Tue, 24 Oct 2006 20:52:30 -0700

The new ruby texexec is very confused. The problem of output defaulting to pdf instead of dvi has already been noted. Here are some additional problems:

Command: texexec --output=dvips foo Should produce: foo.dvi Actually produces: foo.pdf

hm, i need to check that, maybe there is no dvips option

...

Command: texexec --dvi foo Should produce: foo.dvi Actually produces: foo.dvi AND OVERWRITES foo.ps

--Mike Bird

Norbert Preining wrote: that's because the backend is called as well (dvips) ; the latest version has a --nobackend option

----- End forwarded message -----

----- Forwarded message from Mike Bird -----

...

From: Mike Bird Subject: Is texmfstart secure? To: debian-tex-maint@lists.debian.org Date: Tue, 24 Oct 2006 21:08:53 -0700

Package: context 2006.08.08-0.4

If anyone who knows Ruby has time, can you tell if texmfstart is secure? I was really surprised to see client-server code. Even localhost services can lead to privilege escalation if not careful.

hm, if you don't invoke that code it's not used so there can hardly be a leak then;

...

For example, /usr/share/texmf/scripts/context/ruby/texmfstart.rb contains the following. I'm not a Ruby programmer but the comment leads me to think there is a potential problem here:

# danger lurking buffer = ' ' * 260 length = filemethod.call(filename,buffer,buffer.size) if length>0 then return buffer.slice(0..length-1)

...

It looks like PRAGMA is trying to reinvent kpsewhich, integrate internet

well, it's mostly a wrapper around kpsewhich; it would be natural to have kpse as a library but (1) it's not stable [api cq. names changes] and i don't see a stable kpse lib usable in script languages show up; (and yes: i rewrote kpse in ruby, and surprise, in some case it even runs faster than the c version); consider that in context there can be runs with (say) 400 calls to metapost and then it really pays off to bypass this ls-r loading

...

explorer, launch editors, and do a whole bunch of other stuff I haven't

...

figured out. texexec should be a simple wrapper around tex or pdftex but it works via texmfstart.rb which is 2541 lines of Ruby - and that's a lot of Ruby. It may all be wonderful (I am not a Ruby programmer) but

well, if kpse* would have evolved ... sure, but it didn't; also, since i run tex on windows, linux and macosx, i want one launcher for all of

...

it makes me nervous.

well, i would be more worried about tons of cryptic perl code, even if i've written it myself, after a few years i can no longer figure out what it does;

...

Is an older/simpler texexec still available?

the server/client code is a bit experimental and is related to distributed ruby code; imagine a situation where one has many (frozen) tex trees on a server that is used for automated tex processing; in that case, instead of calling kpsewhich each time, a service will keep the file databases (for multiple trees) in memory etc etc ; as said, the average user never enters this code, and it's not even loaded when your system is not explicitly configured to do so this has to do with windows long/short names and this branch is never entered under unix ; also, buffer is just a string and has nothing to do with "buffers that produce those buffer overflows" this launching is only used when one starts documentation -- we use this in editors: context sensitive help started by a few keystrokes another option is to use file associations but that has some disadvantaged anyhow, i see no security risks here since all happens inside the tex domain; i don't need tex to crash an internet browser (on any system) -) them, not all kind of os dependent scripts there is still texexec.pl (will always be around) but i will no longer develop the perl scripts Hans -- ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------