[tex-k] xdvi 22.40i status

[Stefan Ulrich]

First of all, Mike, thanks for your great help on this - really
appreciate it.

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

> Now, back in January, they were discussing the security updates and
> Raph wrote:
[...]
>> Much more troubling is the fact that gv is now broken. Here's why:
[...]
>> When we were discussing this patch, we were unsure if there were any
>> users who used -DSAFER but required read access to arbitrary files.
>> Now we know. Too bad it's taken until now to turn up.

Hmm. Strange these guys wouldn't check compatibility with
applications regularly, at least when testing such new features
... oh well.

> then he wrote:
> http://www.ghostscript.com/pipermail/gs-code-review/2002-January/001756.html

>> As we discussed, it's not necessary if we make -dSAFER open up
>> read file permissions, but it sounds like we're going to do that
>> for the GS_6_5 and GS_7_0X branches only, while in HEAD -dSAFER
>> will lock down read permissions as in your current patch, and as
>> -dPARANOIDSAFER will on the release branches.

at that point it still sounds as if `proper' releases might
behave differently from HEAD wrt. -dSAFER. Dunno how this
transfers to the current testing releases though.

[...]
> then Peter further wrote:
> http://www.ghostscript.com/pipermail/gs-code-review/2002-January/001758.html

>> Correction: gv will work correctly with both versions if it uses *both*
>> -dSAFER *and* -dPARANOIDSAFER.  The patch that will be applied to the GPL
>> branches should explicitly include a warning that the meaning of -dSAFER
>> will be changing, and should instruct application writers to use *both*
>> switches if they want compatibility with both branches.

This I don't understand. Why on earth would gv want to use
-dPARANOIDSAFER? I for one don't want compatibility with the new,
broken behaviour of -dSAFER; I want compatibility with the old,
working one :-(


>> After discussion with Raph, Peter, Ralph and others, we have decided
>> that command line specifiers of OutputFile will not be affected by the
>> changes to implement improved security, thus preserving most of the
>> legacy uses of ghostscript.
grrr ...

>> In a future patch which will set .LockSafetyParams true (among other
>> things) when -dSAFER is set (which will become the default), clients
>> such as GSView will need to start Ghostscript with -dNOSAFER, then
>> establish perform a 'save' and switch to the desired device prior to
>> going into SAFER mode which will set .LockSafetyParams true. Device
>> switching can later be accomplished by restoring to that save object
>> and then switching devices, followed by going back into SAFER mode.

That's what I meant in my previous posting by `implementing our
own safety management on the stack'. Sigh.

> I do not know a lot about Postscript, but that looks like a lot more
> work than the old way.

Me neither, but I think so too. Also, to me it makes no sense to
have such (error-prone, etc.) code implemented in $n$ applications
instead of centrally in gs and accessible with a command-line
switch.

> [Note: gs policy may have changed since these were written.]

Yup. Maybe we should open a new thread on gs-developer and try
to find out what the current status is. I'll probably do that
this evening (CEST).

Until later,
-- 
Stefan Ulrich (stefan.ulrich@elexir.de)
+49-89 23 88 86 65 (office)
+49-89 48 95 28 58 (home)