Am Sat, 03 Apr 2021 09:26:56 -0400
schrieb Greg Troxel <gdt%lexort.com@localhost>:
> 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
recommends:
<!--
[…]
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:
- https://askubuntu.com/questions/1127260/imagemagick-convert-not-allowed
(Asked 2 years ago, Active 1 month ago, Viewed 21k times)
- https://stackoverflow.com/questions/52998331/imagemagick-security-policy-pdf-blocking-conversion
(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
installs.
> print/ghostcript-gpl (last GPL version) is egregiously out of date
> (9.06). In my view no one should use it.
Agree.
> 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,
Thomas
--
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