Re: Ghostscript/GhostPDL 9.28 Release Candidate 1
Paul Wessel <[email protected]> Tue, 20 Aug 2019 03:52:39 -0400
| Newsgroups | gmane.comp.printing.ghostscript.devel |
|---|---|
| Message-ID | <CANDdAJDr-0FKxCXXA=63=D-_r9m+VZXzXyWaBueVG_D=_0JGOA@mail.gmail.com> |
--000000000000c0fa7a059087bda6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 =E2=80=9C.setsafe=E2=80=9D 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 > --000000000000c0fa7a059087bda6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style>= </head><body><div style=3D"font-family:Helvetica,Arial;font-size:13px">Apol= ogies if I misunderstood, but when you say file access controls I am not su= re what you mean.=C2=A0 Do you mean PostScript code that tries to access th= e file system and read named files?=C2=A0 We do no such thing that I am awa= re of, unless this includes procedures that read from the current PostScrip= t file related to the image operator.</div><div style=3D"font-family:Helvet= ica,Arial;font-size:13px"><br></div><div style=3D"font-family:Helvetica,Ari= al;font-size:13px">We will =C2=A0try the -c =E2=80=9C.setsafe=E2=80=9D and = report back.</div><div style=3D"font-family:Helvetica,Arial;font-size:13px"= ><br></div><div style=3D"font-family:Helvetica,Arial;font-size:13px">-p</di= v><div style=3D"font-family:Helvetica,Arial;font-size:13px"><br></div><div = style=3D"font-family:Helvetica,Arial;font-size:13px">On August 19, 2019 at = 9:23:26 PM, Chris Liddell (<a href=3D"mailto:[email protected]">chr= [email protected]</a>) wrote:</div> <blockquote type=3D"cite" class=3D= "clean_bq"><span><div><div></div><div>There are no "Adobe PDF transpar= ency extensions" in Postscript. <br> <br>I'll assume you mean the Ghostcript transparency operators, in whic= h <br>case, yes, that's how we intend it to work. For various reasons (no= t all <br>of them good), the low-level transparency implementation is *very* <br>sensitive to things like calling order, correct parameters etc. Also, <br>it's extremely complex, until we have time to harden that code, we = feel <br>it's better to restrict access to it. <br> <br>So, yes, that is how we intend that stuff to work from 9.28 onwards <br>(note, it doesn't affect transparency in PDF files). <br> <br>If you want to retain access to the transparency operators, but also <br>have the file access controls in force, you can use -dNOSAFER, and then <br>do: -c ".setsafe" -f <input file>.ps <br> <br>If that works as you required, I'd be willing to look at a -dFILESA= FER <br>option, that enables file access controls, but leaves that unsafe <br>operators still available. <br> <br>Chris <br> <br> <br>On 19/08/2019 19:21, Paul Wessel wrote: <br>> Hi Chris et al- <br>> =20 <br>> GMT (<a href=3D"http://www.generic-mapping-tools.org">www.generic-= mapping-tools.org</a>) uses gs to convert from PostScript to a <br>> variety of formats, including PDF. We allow for transparency via = the Adobe <br>> PDF transparency extensions. This has worked fine until 9.28 rc1 = which I <br>> assume have placed those operators under NOSAFER? We find if we a= dd -dNOSAFER <br>> then the expected behavior returns. Is this how you intended tran= sparency <br>> to work from 9.28 onwards? <br>> =20 <br>> Cheer, Paul Wessel <br>> =20 <br>> =20 <br>> On August 15, 2019 at 11:12:45 PM, Chris Liddell (<a href=3D"mailt= o:[email protected]">[email protected]</a>) <br>> wrote: <br>> =20 <br>> I have created archives (and Ghostscript Windows installers) for t= he <br>> first public release candidates for Ghostscript and GhostPDL 9.28,= and <br>> they are available here: <br>> =20 <br>> <a href=3D"https://github.com/ArtifexSoftware/ghostpdl-downloads/r= eleases/tag/gs928rc1">https://github.com/ArtifexSoftware/ghostpdl-downloads= /releases/tag/gs928rc1</a> <br>> =20 <br>> =20 <br>> There are some very important changes in this release: <br>> =20 <br>> First: we have ground-up rewritten the file access controls that w= ere <br>> the major benefit of the "SAFER" code. <br>> =20 <br>> Second: as we've promised (threatened?) for years, SAFER is no= w enabled <br>> by default (it can still be disabled with "-dNOSAFER"). <br>> =20 <br>> Third: those of you still paying attention will probably have work= ed out <br>> that the implication of the above two points is that some very new= code <br>> is being enabled by default! <br>> =20 <br>> As a consequence, we want to give users an extended chance to find= what <br>> we did wrong. <br>> =20 <br>> Note that the previous SAFER behaviour can still be accessed by us= ing <br>> "-dSAFER -dOLDSAFER" - but this will only be true until = we're convinced <br>> we've got no reason to keep the old behaviour. <br>> =20 <br>> =20 <br>> Although we're starting this release candidate process early, = we're <br>> still targetting the 9.28 release on the "normal" schedu= le (late <br>> September/early Oct), in order to give as much testing time as pos= sible <br>> for the new code. <br>> =20 <br>> =20 <br>> Please give the release candidate a try on your system if you'= re <br>> interested in helping test the release-in-progress. Your feedback = is <br>> always appreciated, but especially so with this release. <br>> =20 <br>> =20 <br>> All the best, <br>> =20 <br>> Chris <br>> =20 <br></div></div></span></blockquote></body></html> --000000000000c0fa7a059087bda6--