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

[David Kastrup]

Arash Esbati <address@hidden> writes:

> Ken Sharp <address@hidden> writes:
>
>> The problem is that PostScript is a programming language, and the
>> snippets above, intermingled with some other language, are a)
>> difficult to read and b) shorn of context. Its hard for me to pick out
>> just the PostScript from whatever the other language is and without
>> knowing what the aim is its pretty much impossible to figure out what
>> the PostScript is doing.
>
> Hi Ken,
>
> thanks for your response.  I was afraid that the solution would not be
> that easy by just replacing some PostScript-code in an Elisp-function
> :-)
>
>> I don't suppose there's anyone still around who knows what the
>> PostScript is supposed to do ? I really need to discuss this with
>> someone who understands the intended purpose of that PostScript code.
>
> David K. is the principle author of preview-latex and he is still
> around.  I hope he can manage to find a solution with you, somehow.

I've committed an (admittedly ugly) fix to AUCTeX master.  Most of the
work had actually already been done in previous commits, something which
I had not properly remembered, so we did not actually use .runandhide in
a security-relevant context any more.  My participation in the
discussion was based on remembering an earlier implementation we used,
so the resulting controversy was disproportionate to the impact of the
actually needed fix.

While I cannot presume to understand the motivation of the Ghostscript
developers in removing the documented operator intended to facilitate
temporarily entering safe mode while interpreting externally provided
files without working replacement (the jobserver functionality in the
official PostScript standard has a known large security hole in
Ghostscript's implementation and is not suggested in -dSAFER
documentation for use anyway), the truth was that preview-latex already
had stopped relying on the security-related aspects of .runandhide in a
previous iteration of our code.

So the comparatively simplistic fix I committed does not really come
with security implications as we don't retain a way for leaving the
-dSAFER sandbox once entering it.

-- 
David Kastrup