Norbert Preining wrote: > 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 <[EMAIL PROTECTED]> ----- > >> From: Mike Bird <[EMAIL PROTECTED]> >> Subject: New texexec very confused >> To: [EMAIL PROTECTED] >> 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 >> 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 <[EMAIL PROTECTED]> ----- > >> From: Mike Bird <[EMAIL PROTECTED]> >> Subject: Is texmfstart secure? >> To: [EMAIL PROTECTED] >> 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; 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 >> 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) >> 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" >> 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 >> 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) -) >> 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 them, not all kind of os dependent scripts >> 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? >> 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 ----------------------------------------------------------------- _______________________________________________ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context