Re: Ghostscript/GhostPDL 9.28 Release Candidate 1

There are no "Adobe PDF transparency extensions" in Postscript.

I'll assume you mean the Ghostcript transparency operators, in which
case, yes, that's how we intend it to work. For various reasons (not all
of them good), the low-level transparency implementation is *very*
sensitive to things like calling order, correct parameters etc. Also,
it's extremely complex, until we have time to harden that code, we feel
it's better to restrict access to it.

So, yes, that is how we intend that stuff to work from 9.28 onwards
(note, it doesn't affect transparency in PDF files).

If you want to retain access to the transparency operators, but also
have the file access controls in force, you can use -dNOSAFER, and then
do: -c ".setsafe" -f <input file>.ps

If that works as you required, I'd be willing to look at a -dFILESAFER
option, that enables file access controls, but leaves that unsafe
operators still available.

Chris


On 19/08/2019 19:21, Paul Wessel wrote:
> Hi Chris et al-
> 
> GMT (www.generic-mapping-tools.org) uses gs to convert from PostScript to a
> variety of formats, including PDF.  We allow for transparency via the Adobe
> PDF transparency extensions.  This has worked fine until 9.28 rc1 which I
> assume have placed those operators under NOSAFER?  We find if we add -dNOSAFER
> then the expected behavior returns.  Is this how you intended transparency
> to work from 9.28 onwards?
> 
> Cheer, Paul Wessel
> 
> 
> On August 15, 2019 at 11:12:45 PM, Chris Liddell ([email protected])
> wrote:
> 
> I have created archives (and Ghostscript Windows installers) for the
> first public release candidates for Ghostscript and GhostPDL 9.28, and
> they are available here:
> 
> https://github.com/ArtifexSoftware/ghostpdl-downloads/releases/tag/gs928rc1
> 
> 
> There are some very important changes in this release:
> 
> First: we have ground-up rewritten the file access controls that were
> the major benefit of the "SAFER" code.
> 
> Second: as we've promised (threatened?) for years, SAFER is now enabled
> by default (it can still be disabled with "-dNOSAFER").
> 
> Third: those of you still paying attention will probably have worked out
> that the implication of the above two points is that some very new code
> is being enabled by default!
> 
> As a consequence, we want to give users an extended chance to find what
> we did wrong.
> 
> Note that the previous SAFER behaviour can still be accessed by using
> "-dSAFER -dOLDSAFER" - but this will only be true until we're convinced
> we've got no reason to keep the old behaviour.
> 
> 
> Although we're starting this release candidate process early, we're
> still targetting the 9.28 release on the "normal" schedule (late
> September/early Oct), in order to give as much testing time as possible
> for the new code.
> 
> 
> Please give the release candidate a try on your system if you're
> interested in helping test the release-in-progress. Your feedback is
> always appreciated, but especially so with this release.
> 
> 
> All the best,
> 
> Chris
>