Re: Ghostscript/GhostPDL 9.28 Release Candidate 1

The whole point of SAFER is to restrict access
(reading/writing/creating/deleting etc) to files that malicious
Postscript code might be interested in. So we implement lists
(PermitRead/PermitWrite/PermitControl) of files, directories and
directory trees and, previoously, Postscript files were only allowed
appropriate access to files/directories in those lists.

*Now*, with the new code, by default, *all* file accesses are under
those controls (not just access stemming from Postscript programs).

We've tried to make this as transparent for the vast majority of users
as we can: for example, the input file and output file(s) specified on
the command line are automatically added to the requisite lists
(PermitRead and PermitWrite respectively).

If you only run Postscript from a "closed" workflow (as I assume you do,
given your use of the custom transparency operators), then there is no
advantage to you in using SAFER, and you would be absolutely fine adding
-dNOSAFER to your command line, and leaving it at that.

The problem is, *most* users don't work in a closed workflow, and also
don't even remotely understand that Postscript is a programming
language, so they are at risk from malicious Postscript. Hence the
rewrite of file access controls, and enabling them by default.

("currentfile" operates on an already open file object, so file access
controls have no affect on it).

Chris


On 20/08/2019 08:52, Paul Wessel wrote:
> Apologies if I misunderstood, but when you say file access controls I am
> not sure what you mean.  Do you mean PostScript code that tries to access
> the file system and read named files?  We do no such thing that I am aware
> of, unless this includes procedures that read from the current PostScript
> file related to the image operator.
> 
> We will  try the -c “.setsafe” and report back.
> 
> -p
> 
> On August 19, 2019 at 9:23:26 PM, Chris Liddell ([email protected])
> wrote:
> 
> 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
>>
>