Bug 701624 - pdf2ps does not handle transparency in SAFER mode
Summary: pdf2ps does not handle transparency in SAFER mode
Status: RESOLVED WONTFIX
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Transparency (show other bugs)
Version: 9.27
Hardware: PC Linux
: P4 normal
Assignee: Michael Vrhel
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-09-24 15:27 UTC by Jonas Smedegaard
Modified: 2019-10-02 17:49 UTC (History)
1 user (show)

See Also:
Customer:
Word Size: ---


Attachments
simple LaTeX transparency test (107.94 KB, application/postscript)
2019-09-24 15:27 UTC, Jonas Smedegaard
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jonas Smedegaard 2019-09-24 15:27:28 UTC
Created attachment 18164 [details]
simple LaTeX transparency test

A Debian user reports at https://bugs.debian.org/941074 that pdf2ps fails to handle transparency in SAFER mode.

From above bugreport:

To reproduce the bug, run

  ps2pdf14 transparent-things.ps

(no transparency in transparent-things.pdf) and

  ps2pdf14 -dNOSAFER transparent-things.ps

(transparency in transparent-things.pdf).
Comment 1 Ken Sharp 2019-09-30 14:54:18 UTC
PostScript does not support transparency (with some caveats). Ghostscript has some, entirely non-standard, operators to apply the PDF transparency model in PostScript.

These extensions are fragile; using them in the wrong order, or simply in ways that our code doesn't normally use them, can lead to segmentation faults and core dumps.

(Note that a quick peruse of the supplied example file suggests it is not using the Ghostscript transparency operators correctly. I'm somewhat surprised this file produces the output it does, since it doe snot push the PDF14 compositor at all. Even if it works now, its likely to fail in the future.)

Since they are non-standard, and liable to cause errors, the decision was taken to restrict their usage when running PostScript, as this is (obviously) a security risk. A malicious user might be able to take advantage of a crash.

In addition, previously the default was to run Ghostscript withou SAFER but, as we've been warning for years (if not decades) that we intended at some future date to make SAFER the default, we've now decided (in the light of recent security reports) to implement that.

The LaTeX PostScript program looks for the presence of the Ghostscript-specific operators it is using, and implements 'bit bucket' versions of them if they are not found. This prevents Ghostscript from throwing an error, which is why the result silently omits the transparency.

That's not the fault of Ghostscript, its a deliberate decision on the part of the PostScript programmer.

So, if you want to use these non-standard operators, you are going to have to run Ghostscript with -dNOSAFER.