"Dr. Thomas Orgis" <thomas.orgis%uni-hamburg.de@localhost> writes:
> 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}" />
> -->
But that's in a comment, not what upstream installs, and upstream does
not suggest that this should be part of a default install.
> 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.
Again I am not really following. I think the disconnect is that you are
proposing a change and I therefore expect analysis and rationale that
does not require the reader to repeat the exercise of looking into
ImageMagick deeply. This is the first I have followed about desktop vs
web and I am now unclear if there is some notion of which in the
environment that affects the policy file.
>> Is imagemagick still maintained upstream?
>
> Of course, you can also discuss switching to GraphicsMagick instead.
> Both projects are alive upstream and in competition.
So does GraphicsMagick do something different? Does it install the same
set of files? Should pkgsrc consider makign GraphicsMagick the default
Imagemagick implementation?
>> 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.
Which means upstream thinks that the defaults they ship are appropriate
for general 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.
So, no, there isn't really a norm, except some do "none" and some don't
do anything, and we don't know about a bunch of others.
>> 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.
OK - glad I understood what you meant.
>> 2) about other policy changes
>>
>> Has this been filed upstream? response?
>
> Which upstream? It's the distros applying this strict policy.
I meant to ImageMagick. You are basically asserting that it's a bug in
ImageMagick that ghostscript is not turned off in the installed policy
file. I don't want to say that pkgsrc should never make changes on
security grounds, just that in doing so I see us as fixing a bug in
upstream, and our norms call for filing that fix upstream. But if
that's pointless and annoying, best not to and the patch comment should
say that.
It seems clear that fundamentally upstream ImageMagick thinks their
default config is right and you (and probably others) think their
default is not right. That's ok - we just need to be clear on what's
going on and have that understanding be reflected in pkgsrc bits so
someone who doesn't understand this and reads the package control files
will understand.
>> 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.’
I don't really see the 'notified early' point. pkgsrc has lots of
software under a huge number of licenses and some of them are in
DEFAULT_ACCEPTABLE and some are not. This is a far more general
problem.
One could also argue that a program depending on another program with a
license further up the BSD->GPL->AGPL chain is a bug in the depending
program.
Your declaration of "defaults don't work" and "if you want to use pkgsrc
you must set this" is a mischaracterization. There are multiple people
with multiple requirements, and "work" when uttered by someone often
means "meets *my* requirements".
From a security and compliance point of view, "work" usually means
"things that are not supposed to happen don't happen". The argument
here is only about the default, and thus which group has a
failure-to-do-what-I-want. Right now, people who try to build
ghostscript-agpl get an error message about adding to
DEFAULT_ACCEPTABLE, and -- if they are ok with AGPL -- they do that.
It's in my view not a big deal -- I put it in my mk.conf ages ago and
haven't had an issue since. The situation has been unchanged for a long
time, and there have been no reports of true difficulties.
This is not documented in the guide as well as it should be -- the
entire LICENSE handling part, and what is in DEFAULT_ACCEPTABLE is
missing. To me that's the very first thing to fix. However, read
mk/license.mk which explains it.
Attachment:
signature.asc
Description: PGP signature