[tex-k] dvips 5.86f issues; xdvi with gs 7.04

[M. Shell]

Hi folks,
 
 While trying out the latest dvips 5.86f I discovered a few things that
I think need some attention.



(1) During the course of validating the new configuration file security
option, it became apparent that all backtick escapes do not work -
even in non-secure mode!


Looking through the code, I traced the problem to line 177 of output.c:


     if (secure == 0) {
         (void)sprintf(errbuf, "Execution of  <%s> failed ", s) ;
         f = popen(s, FOPEN_RBIN_MODE) ;
     }
     
     
Now, in 2000-04-02 the kapthsea library headers were changed so that
FOPEN_RBIN_MODE is now defined as "rb" even on UNIX systems. This is OK
with GNU fopen() as it will automatically ignore the binary mode directive.
However, popen() has never tolerated a "b" in the mode string 
(at least on Linux) and will always fail as a result.

So it seems the June 2001 discussion of securing dvips was a mute point
as it has *really* been secure on UNIX since 4/2000 ;)

The correction is to use a hard-coded "r":

 f = popen(s, "r");

and dvips will then work as intended.



(2) on another security related note, I noticed that dvips still defaults
to non-secure mode unless the "z" directive is placed in its configuration
file. Should it not _default_ to secure mode? The sys-admin can always
place a "z0" in a config file if the opposite is desired. The way things
are now, dvips will not default to running securely when it is used with
older configuration files. (And there is a large existing code base of
config.ps files!).



(3) The INSTALL file of the teTeX distribution has a much appreciated
discussion in Appendix B on the moving of binaries. Of particular interest
to me is:


"- make sure that TEXMFMAIN is defined correctly in the texmf.cnf file.
  Execute the command
      kpsewhich -expand-var='$TEXMFMAIN'
  If this does not give you the root of your texmf directory, you have to
  correct the TEXMFMAIN variable. Juch change the line which defines..."
  
  
This is correct (apart from the misspelling of "just" ;), but it needs to
say a little more. For instance, in texmf.cnf, Red Hat Linux 6.0 has:

TEXMFMAIN = $SELFAUTODIR/share/texmf

Now, this will result in a very confusing situation when a user trys to
put their new dvips in /usr/local/bin, when their <texmf> is 
/usr/share/texmf. The new dvips will not be able to find its header files
even though kpsewhich returns the correct texmf directory. However, the
newly compiled dvips will work just fine from /usr/bin. (This is normal,
right?)

If I understand things correctly (and my understanding of Kpathsea is
very limited) and my dvips 586f source was correctly configured, IMHO the
teTeX INSTALL should also mention:

 (a) that $SELFAUTODIR can cause problems when executables are located in
"nonstandard" locations

 (b) the problem can be avoided by using a single full path to TEXMFMAIN,
i.e., TEXMFMAIN = /usr/share/texmf
<or> by placing the new executable in the same directory as the original
one (although possibly with a new name).



(4) I was also trying out the new 7.04 of Ghostscript and I noted that its
new security measures break xdvi's ability to preview graphics if these
graphics use relative path names. i.e., 

\includegraphics{../eps/fig.eps}

will stop xdvi from being able to show previews 
(Ghostscript errors with "/invalidfileaccess in --file--"), but

\includegraphics{/home/usr/eps/fig.eps}

works just fine with xdvi. This looks like a GhostScript bug (and I have
reported it to the GhostScript developers), but I thought you all might
like to know before users start thinking xdvi is broken. Ghostscript 7.03
does not exhibit the problem (but may have more security issues).



 Thank you,

  Mike Shell
  mshell@ece.gatech.edu
 
 
PS: How is the evaluation of dvips 5.86f coming along? Does it seem to be
robust with respect to subsetting, etc.?