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

[David Kastrup]

Ken Sharp <address@hidden> writes:

> At 19:24 05/11/2017 +0100, you wrote:
>
>
>> > 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 .
>
> You don't need .runandhide to execute 'unsafe' code,

We use it to execute potentially unsafe code in a SAFER environment.
But we need to get back to non-SAFER mode afterwards without the
potentially unsafe code having a possibility to get into non-SAFER mode.

>>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).
>
> But I would very much like to see the sequence of operations, and more
> importantly the whole PostScript program, or at least all the initial
> program. Its terribly hard to make judgements based on a couple of
> program fragments with no context to draw on.

Ok, will do tomorrow.

>> > 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.
>
> Well I'm sorry, clearly I'm being obtuse. From my perspective you are
> explaining that 'you need to run unsafe code' or 'you need it because
> you need to execute in an arbitrary order'. OK I'm not arguing any of
> that, but I don't see why you specifically need .runandhide in order
> to do so.

Because we want to execute potentially unsafe code not under our control
in SAFER mode and afterwards get back into non-SAFER mode in order to
things not allowed in SAFER mode.  Repeatedly.

> I need a more detailed explanation, why specifically do you need
> .runandhide instead of say exec ?

Because exec will either not run in SAFER mode or not get back into
non-SAFER mode.

>>That makes it hard to guess where to invest work next with the hope
>>for success.
>
> Well, I've asked for a transcript of what gets sent to Ghostscript,
> that would help. Even just the actual initial PostScript program would
> tell me more than what I've seen so far.

As I said, I will do.  Though our conversation so far is not exactly
leaving much hope for this to explain anything in a clearer manner than
I already did.

> Interesting, in what way has Ghostscript changed in the past that's
> caused you problems ? Have you discussed this with anyone ? While I do
> see your name in the archives, it appears to be mostly in discussion
> with me. Once due to strokeadjust and PDF, and once with some other
> Lilypond stuff. I haven't seen anything from AucTeX before. Of course,
> it could easily predate my involvement.

About half of the changes were done by me, the other half by Ralf
Angeli.  So far either of us had been able to find yet another
workaround.  But without anything like .runandhide left, I don't see
what we could be doing next.

> Obviously if there are bugs in the PostScript implementation we have
> to fix them, but that's comparatively rare I would have thought these
> days.

Those were not exactly bugs but changes in semantics, usually about what
was considered SAFER and what not.  SAFER mode is not in PostScript, so
one cannot really talk about "bugs" for that.  More like inconveniences
in the context of refining SAFER.  A nuisance, but not of the
break-of-promises kind.

.runandhide is certainly not part of the PostScript standard, but it was
a documented part of Ghostscript.

>>   If there was any way guaranteed to actually
>>stay around, that would be quite the relief.
>
> Well, first and most obvious would be not to use non-standard
> PostScript.

> But you can't simply do that because (it seems to me) you want to run
> Ghostscript 'interactively', except that you don't really mean
> interactively, you really mean in something like a job server
> loop. Interactively to me would mean would mean from the GS command
> prompt.

Sigh.  As I stated several times already, we do run Ghostscript from the
GS command prompt.  We even wait for the prompt before feeding it its
next command.

> Now to me that would suggest that rather than launching Ghostscript
> and leaving it lying around until you want to send it something, you
> launch it once per PostScript program, and close it in between.

No, we don't.  We run it from the command prompt and don't close it in
between.

> You don't want to do that, and I can accept that, but I still do not
> at present understand the way you are using Ghostscript now.

>From the command prompt.  On a pseudo-tty or a pipe (not much of a
difference to Emacs).  That's why your transcript will be teed off from
a script called instead of Ghostscript: if we didn't feed it via its
input and interpreted its output, there would be nothing to tee off.

> Nor do I understand the absolute requirement for .runandhide.

How do you get temporarily into SAFER mode for executing a file without
it?  I keep asking this question.

> Well, the actual PostScript program would give me context. If you can
> explain why you specifically need .runandhide rather than simply
> running in -dSAFER and using exec that would be good.

If I can't get back out of -dSAFER mode I cannot at the end of
processing of one file select a file in a preview-latex chosen place to
execute next.  That's what -dSAFER prohibits.

> Also why you need to launch Ghostscript and leave it running, rather
> than launching it once for each PostScript program, though that's
> rather less important (though possibly easier to explain).

A performance hit by a factor of 10 if not more.  preview-latex creates
an image for every mathematical entity in a document, easily several
thousands of them, often just a few characters each.  Having to start a
fresh Ghostscript process for them that then has to read the fonts
(which are rarely more than a few dozen per document) would be
prohibitively expensive.  Doing all this in a single Ghostscript process
made preview-latex an actually useful tool rather than a toy.

>>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.
>
> Yes but I still don't see why you need .runandhide to achieve this.

You haven't mentioned any alternative way of doing 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.
>
> And the unsafe context you are storing is what exactly ?

The object you get when executing "safe" before executing .setsafe.
Calling restore on it reverts to non-safe mode, so we don't want it
accessible to the potentially unsafe code executed in -dSAFER mode.

I mean, that's the textbook and documented way of using .runandhide .
It's not like we invented it.

> Usually these result in crashes but we've also seen denial of service,
> directory and file traversal/retrieval and some cases where it was
> possible to execute arbitrary code. Note that these have been true in
> some instances even when -dSAFER is set.

Calling "safe" in unsafe mode will deliver an object useful for
returning from -dSAFER _if_ code has access to that object.  .runandhide
was the documented way of hiding the object away from potentially unsafe
code.

-- 
David Kastrup