[tex-k] xdvi 22.40i status

Stefan Ulrich stefan.ulrich@elexir.de
Thu, 11 Apr 2002 10:18:35 +0200

M Shell <mshell@ece.gatech.edu> writes:

> Maybe there is a much easier way. The SF bug report I posted
> has already been assigned.

Great! FWIW, I've posted a small followup emphasizing the
xdvi perspective on this (similar to what I've written below,

> So, in the next few weeks/months the ../ problem will be
> history. Since the 7.01-7.04 series have quite a few biting
> bugs, upgrading to later versions will be a priority
> anyway. So, all we have to do is sit back and let Ghostscript
> "heal" itself. ;)

OK; however I don't agree with the following:

> The -dSAFER issue may be easy to deal with too. All that
> is needed is for users to update their XDvi config file to
> turn off -dSAFER with later versions of gs.

I think we don't really want to do this, since it would allow
remotely fetched DVI files to contain malicious Postscript code
that deletes arbitrary files in your home directory! IMHO it
would be rather ironic if a planned security improvement in gs
(with -dPARANOIDSAFER) would lead to such an actual *degradation*
in security for the ordinary user.

(Also, if users need to toggle -dSAFER on a per-file basis in
order to be able to view their own PS files, they are bound to
globally switch to -nosafer sooner or later.)

If the ghostscript people don't change their mind, I guess we'll
have to either provide a custom gs_init.ps file that makes
-dSAFER behave as it did before (unclear how to manage that), or
implement our own safety management on the stack instead of just
passing -dSAFER to gs; it seems that once turned on via -dSAFER,
the security settings can't be turned off again on the Postscript
level (which of course makes sense, otherwise -dSAFER would be
pretty useless in the first place).

For the time being, you're right, we'll need to wait and see
what they respond to our your bug report.

Stefan Ulrich