tech-pkg archive

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

Re: misguided ImageMagick polixy.xml settings regarding PS/PDF and ignorance about other problematic coders

Am Sat, 03 Apr 2021 09:26:56 -0400
schrieb Greg Troxel <>: 

> 1) about the proposed patch
> I see your point about PS creation not being problematic.  I'm not sure
> if everyone agrees -- the question is if there is some other
> not-thought-of problem.

> Generally pkgsrc tries to follow upstream, unless that's not a good
> idea, and I did not absorb from your message:

My point on that is that it gets rid of the obvious attack vector of
untrusted input. ImageMagick contains loads of code and bindings to
parser libraries … so the more sensible approach for what this policy
was to address is what the current upstream example policy.xml

  Rules are processed in order.  Here we want to restrict ImageMagick to only
  read or write a small subset of proven web-safe image types:

    <policy domain="delegate" rights="none" pattern="*" />
    <policy domain="filter" rights="none" pattern="*" />
    <policy domain="coder" rights="none" pattern="*" />
    <policy domain="coder" rights="read|write" pattern="{GIF,JPEG,PNG,WEBP}" />

I think best-practice for the scenarios that this hotfix of disabling
gs was supposed to cover is to provide the web service with a custom
safe config for that use-case and leave desktop users alone, working on
their graphics files as expected without a program refusing to load an
image because there have been some bugs years ago. Looking at the list
of past bugs in IM, you'd have to disable _all_ formats to be safe.

>   Is imagemagick still maintained upstream?

Of course, you can also discuss switching to GraphicsMagick instead.
Both projects are alive upstream and in competition.

>   Does upstream have an opinion?   If we still need to patch, have you
>   or someone filed a bug upstream?

See above. Their default does not impose any limits and suggests
configuration by the admin depending on use.

>   Is there a norm among other packaging systems about what to do
>   (demonstrating some sort of consensus that upstream's choices should
>   be overridden)

I did not see any policy stuff in fedora's spec file. Debian has the
"none" change like pkgsrc. And annoys me each time I want to work with
my files to produce PDF from bitmaps on a fresh install.

>   Is this still an issue with current ghostscript?

The known issues have been fixed, AFAIK. Of course there are very
likely a number left waiting to be discovered, like in other complex
software we use daily.

>   But arguably this has turned into
>   "ghostcript will always be too scary to run on untrusted input" and
>   it's now about avoiding bugs we don't know about.  Is that correct?

Yes. People are just scared and many folks don't miss PS/PDF, perhaps.
There is noticeable irritation/confusion among users:

  (Asked 2 years ago, Active 1 month ago, Viewed 21k times)
  (2 years, 5 months ago, Active 1 month ago, Viewed 121k times)

Not sure if people bothered asking the distros to roll back the change.
I mean, they of course updated gs ASAP … _and_ applied the workaround
for non-updated gs. Sounds a bit unfair to me.

> 2) about other policy changes
>   Has this been filed upstream?  response?

Which upstream? It's the distros applying this strict policy.

>   consensus of other distributions?

Not sure. I guess there are distros that include the strict proposal of
"none" and didn't bother since, and others who ship the default config
by upstream.

> 3) Ghostscript AGPL

[prior discusson and settlement on no-APGL-default in pkgsrc]

I have other battles to fight, too, but since there is _no_ viable
alternative now, this can might have to be opened again, at minimum for
special-casing ghostscript, or just convince the people who want to
ensure no AGPL code to change the defaults to forbid it in their

>   print/ghostcript-gpl (last GPL version) is egregiously out of date
>   (9.06).  In my view no one should use it.


>   So yes, this leads to programs that use ghostscript failing to build
>   unless you choose to put AGPL in ACCEPTABLE_LICENSES.  There are other
>   cases in pkgsrch (or were) where programs that have Free licenses
>   depend on things that aren't in DEFAULT_ACCEPTABLE.  That's just how
>   it is, and people have to deal.

I support the idea that users should be notified of this early
(bootstrap notes, options?). Though, this seems prone to become a case
of ‘I you want to use pkgsrc, do this, that … and always apply these
changes to the defaults, because the defaults don't work.’

Alrighty then,


Dr. Thomas Orgis
Universität Hamburg
RRZ / Basisinfrastruktur / HPC
Schlüterstr. 70
20146 Hamburg
Tel.: 040/42838 8826
Fax: 040/428 38 6270

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Home | Main Index | Thread Index | Old Index