bug#28811: 11.90.2.2017-07-25; preview-at-point

[David Kastrup]

Ken Sharp <address@hidden> writes:

> At 20:45 04/11/2017 +0100, David Kastrup wrote:
>
>
>> > Also WRITESYSTEMDICT and other things.
>> >
>> > In any event, DELAYSAFER hasn't changed.
>>
>>It's pretty pointless unless one can use .runandhide to temporarily be
>>safe.
>
> Make *what* safe ? .runandhide wasn't (directly) an aspect of SAFER or
> DELAYSAFER, its perfectly possible to have, and write PostScript which
> is not compatible with SAFER (and which therefore needs to be run
> before SAFER) but which doesn't require ,runandhide.

The problem is that we need _unsafe_ code to run _after_ SAFER.  From
the Ghostscript command line that gets back into control after
.runandhide has interpreted an external file in SAFER mode .
.runandhide was implemented for that use case: getting back into unsafe
mode without this being possible for the code that is run under control
of the unsafe environment.

>>I repeat: the order of the files to be rendered is not known when
>>Ghostscript is started: that depends on where the viewer is paging when
>>Ghostscript has free capacities.
>>   This "render stuff currently on screen
>>first" thing is pretty important for maintaining good interactivity.
>>.runandhide is used for rendering one file safely, then get Ghostscript
>>back into a state where it is possible to tell it via pipe to its
>>command line what to do next.
>
> OK bear in mind I have yet to see a complete PostScript
> transcript. All I've seen is fragments, buried inside other code.

I can run a script teeing off the in- and output instead of running
Ghostscript directly.  You have to be aware that _any_ such log will
_not_ demonstrate the need for getting back into unsafe mode since once
you know all operations you want to do, you can do all unsafe operations
first and no longer need to revert to unsafe.  The point is that the
user actions determine the next files to be rendered and thus determine
the next unsafe operation (namely which file to open next).

> I have not said 'we're not putting it back', I've said 'let's discuss
> this'. If you can please explain why you can't refactor your
> PostScript to do away with .runandhide then we'll certainly consider
> this.

Well, I keep explaining it without seeing any point being taken up.
That makes it hard to guess where to invest work next with the hope for
success.

> However, all I'm getting (and this may well be my faulty understanding
> from the limited code I've seen) is 'put it back, because we need it
> and we can't change'

You don't propose any way in which we could change in order to render
different files outside of the Ghostscript directories in a
non-prearranged order in safe mode.  We do this from the command line
since that is the basic interaction point for Ghostscript.  Do you see
any other manners to tell Ghostscript "please render _this_ file next,
in SAFER mode, and then return for further (unsafe) instructions".

We've been running around changes in Ghostscript's implementation and
rules at least 5 times.  If there was any way guaranteed to actually
stay around, that would be quite the relief.

> Now I'm prepared to believe that, but I'd like to see why that's
> required, at the moment I don't see why it is. Maybe we can suggest
> alternatives that will be satisfactory.

So what do you actully need?

> So please; send me a simple example of the PostScript that gets sent
> to Ghostscript. If you can arrange for that to be annotated with
> comments explaining what the code does that would be great, if not
> then just the raw code.
>
> I do need to understand why you need .runandhide; what its doing for
> you that you need to have,

Being able to run in safer mode, and _yet_ _afterwards_ specify the next
file to render outside of the Ghostscript accessible tree.

That is all.

> and can't achieve another way.

Is there another way?

> I appreciate that its 'because you don't know what files are going to
> be run' which is fine, but rather high level as an explanation. What
> specifically is .runandhide doing for you that you can't achieve
> without it ?

It puts "unsafe mode" outside of the access of the file running in SAFER
mode while returning back into it.  That's all.  If you have to store
the unsafe context anywhere where the file running in SAFER mode could
access it, there is no actual safety.

> Noote that we went through our own code examples removing the
> requirement from our code, so we are not entirely unfamiliar with
> techniques to deal with this.

So how did you do that?

-- 
David Kastrup