Re: possible issue with ps2pdf (9.25) and transparency

At 12:56 17/09/2018 +0200, Johannes Meixner wrote:


>On Sep 17 10:26 Ken Sharp wrote (excerpt):
>>At 10:55 17/09/2018 +0200, Johannes Meixner wrote:
>>>I assume currently this is not possible but I would appreciate it
>>>when in a future Ghostscript version any non-standard PostScript
>>>extension would only be supported when a special command line
>>>option was explicitly specified that enables the extension.
>>
>>I'm afraid that such a setup would break many existing
>>applications which use Ghostscript.
>
>I don't think so because my crucial point is that the intended
>behaviour can be specified by an appropriate Ghostscript option.
>
>What the default behaviour is is of secondary importance.
>
>E.g. assume there is a Ghostscript command line option
>'-dNOEXTENSIONS' then the current default behaviour
>would not change so that no existing application would
>need to be changed.

Umm, but that's the opposite of what you said above. Or so it seems to me.

Your initial suggestion was that non-standard operators would be supported 
only when a command line option was given (eg -dALLOWPSEXTENSIONS).

But this suggestion is the opposite, where extensions would be supported 
*unless* a command line option was given.

The first one wouldn't work for existing applications, the second, 
obviously, would.


>I assume those PDF interpreter extension operators are required
>while the PDF input pages are processed (and not e.g. only during
>Ghostscript initialization where they could be disabled afterwards)
>so that those extensions need to be available for arbitrary PDF
>input from untrusted origin that might misuse those extensions.

Yes, that's the case, these have to be available at all times. However, we 
can make the effort to ensure those operators check their arguments. This 
is also part of the current internal security review. For what its worth I 
identified and documented 10 areas of concern, some have been completed, 
some are in progress, some will take a little longer. The most crucial ones 
are compelted.


>>Fundamentally I'm pretty happy with bundling the whole file system and 
>>non-standard operator usage together, if you want to do dangerous stuff,
>>then you can't use SAFER.
>
>But then one can no longer run Ghostscript in a strict PostScript compliant
>way which means "all standard PostScript is supported but nothing more".
>
>This is more a theoretical argument because I assume in practice
>99.99% of Ghostscript's users won't care because they never
>use Ghostscript directly but indirectly via other tools.
>
>Nevertheless personally I prefer in general to
>"Keep Separated Issues Separated" ( 'KSIS' ;-)
>cf. item 5 in RFC 1925 at
>https://tools.ietf.org/html/rfc1925

Yeah but in a counter argument, its simpler to have a single setting, which 
we do now by extending SAFER.


>Many thanks in advance for it (and good luck with ducking ;-)

:-) I suspect there will be considerable debate !


>I would much appreciate it if you could tell about the results
>(even if results are "not yet decided").

I'll stick this in my needs attention mailbox and get back to it in early 
October after I get home.


                     Ken