Re: [NTG-context] Two problems with current ruby scripts

25 Oct 2006


      ...
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
-----------------------------------------------------------------