[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#941074: marked as done (ghostscript: ps2pdf SAFER and transparency interference)

Your message dated Sun, 31 Dec 2023 14:33:09 -0600
with message-id <13488466.uLZWGnKmhe@riemann>
and subject line Re: Bug#941074: ghostscript: ps2pdf SAFER and transparency interference
has caused the Debian Bug report #941074,
regarding ghostscript: ps2pdf SAFER and transparency interference
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
941074: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941074
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: ghostscript
Version: 9.27~dfsg-2+deb10u2
Severity: minor

ps2pdf14 as delivered in buster will only produce PDF transparency when
run with -dNOSAFER.  This deviates from previous releases (I'm quite
sure about jessie), when transparency was produced without further
configuration.  Although I *might* see some relationship to accepting
pdfmarks, the connection between SAFER and transparent colours frankly
strikes me as just a little non-intuitive (but that may be because I
don't know what's going on when producing transparency in PDFs).

Because of this, I'd suggest that if turning off PDF transparency
without -dNOSAFER is intentional, that should be documented in the NEWS,
even more so as I couldn't make out that fact in the upstream Use.htm
that the current 9.28~~rc1~dfsg-1 NEWS item refers to.  Perhaps that
particular item could be amended with saying something like "Note that
that has some rather unexpected consequences (e.g., PDF transparency is
now lost without -dNOSAFER)."

Here's my minimal working example:

With the LaTeX document

	\documentclass{article}
	\usepackage{pstricks}
	\begin{document}

	\psframebox*[linecolor=white,fillcolor=red,fillstyle=solid,
      	opacity=0.85,framesep=4mm]{abc}
	\vskip -9mm
	\psframebox*[fillcolor=white, opacity=0.5,strokeopacity=0.5,
  	fillstyle=solid,framesep=4mm,linewidth=3pt,linecolor=black]{abc}

	\end{document}

in a.tex, run

	latex a;dvips a;ps2pdf a.ps

and the second white box obscures most of the red box in the background
(i.e., pstricks opacity is ignored).  Run

	latex a;dvips a;ps2pdf -dNOSAFER a.ps

and the two boxes blend as expected.


-- System Information:
Debian Release: 10.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (x86_64)

Kernel: Linux 5.1.9 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages ghostscript depends on:
ii  libc6   2.28-10
ii  libgs9  9.27~dfsg-2+deb10u2

Versions of packages ghostscript recommends:
ii  gsfonts  1:8.11+urwcyr1.0.7~pre44-4.4

Versions of packages ghostscript suggests:
ii  ghostscript-x  9.27~dfsg-2+deb10u2

-- no debconf information

--- End Message ---
--- Begin Message --- 
Closing this report since this is a deliberate change of behaviour by 
upstream.

On Wed, 27 Nov 2019 17:48:51 +0100 Jonas Smedegaard <jonas@jones.dk> wrote:
> Control: tags -1 wontfix
> 
> Quoting Markus Demleitner (2019-09-24 11:36:09)
> > ps2pdf14 as delivered in buster will only produce PDF transparency 
> > when run with -dNOSAFER.  This deviates from previous releases (I'm 
> > quite sure about jessie), when transparency was produced without 
> > further configuration.  Although I *might* see some relationship to 
> > accepting pdfmarks, the connection between SAFER and transparent 
> > colours frankly strikes me as just a little non-intuitive (but that 
> > may be because I don't know what's going on when producing 
> > transparency in PDFs).
> > 
> > Because of this, I'd suggest that if turning off PDF transparency 
> > without -dNOSAFER is intentional, that should be documented in the 
> > NEWS, even more so as I couldn't make out that fact in the upstream 
> > Use.htm that the current 9.28~~rc1~dfsg-1 NEWS item refers to.  
> > Perhaps that particular item could be amended with saying something 
> > like "Note that that has some rather unexpected consequences (e.g., 
> > PDF transparency is now lost without -dNOSAFER)."
> 
> At https://bugs.ghostscript.com/show_bug.cgi?id=701624#c1 upstream 
> explains that the operators to apply transparency is non-standard when 
> applied to Postscript code.
> 
> Upstream has since relaxed to permit these non-standard operators in 
> SAFER mode, a change which is (not certain but) likely to appear in next 
> upstream release: http://git.ghostscript.com/?p=ghostpdl.git;h=d1eac80
> 
> I prefer to not mess with this security-related code to try cherry-pick 
> for older relases, and therefore flag this bug as wontfix.
> 
> Thanks for reporting,
> 
>  - Jonas
> 
> -- 
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
> 
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private

Attachment: signature.asc
Description: This is a digitally signed message part.


--- End Message ---
Reply to: