New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
remove the necessity to overwrite policy.xml on every upgrade #229
Comments
You can create your own policy.xml in your own directory, which will not change. See https://imagemagick.org/script/resources.php Locations can be:
|
did you read the StackOverflow discussion? |
+1 to this, we are on Heroku and would be great to use the packaged version of IM with an updated policy instead of having to load a different version so we can set the policy correctly (which also bloats our slug size and causes other issues). |
Although the local policy in ImageMagick can override the installed policy, it is limited to imposing further constraints and cannot extend the installed policy. This is because the system administrator has the authority to determine the necessary policies for a specific host. However, if you build an "uninstalled" version of ImageMagick, it will fully comply with your local security policy. As we do not have control over the installation of the ImageMagick package, we are unable to enhance the user experience. If you wish to automatically override any previously applied policies, you must bring the issue to the attention of the package maintainers. On the other hand, if you construct ImageMagick from its source, it will replace an existing policy without raising any concerns. |
Thank you @urban-warrior. I was under the impression that this GitHub repo is the right place where IM is "made" and where the package maintainers would see discussion. Where would I find them? I'll track the package maintainers down. Nevertheless, your remarks puzzle me. There are thousands of packages that permit configuration in |
The discrepancy is due to a security policy configuration. Local ImageMagick configuration files can be added in abundance, superseding system settings. Nevertheless, security policies are typically established by an organization or host administrator. This is not unprecedented, Microsoft Windows, for example, can have security policies set by your organization that can only be changed by an administrator. |
Linux Mint 21.1, up to date.
With every upgrade to IM, the installer notices that I have changed the defaults in
/etc/ImageMagick-6/policy.xml
and asks me whether I wish to overwrite them (image below). This is inapproprate for two reasons.First, the defaults in policy.xml, especially memory and file permissions, are almost never adequate to file processing needs on a modern computer with typical large available memory and large file sizes and types. Many users routinely have to tweak policy.xml just to get IM to work.
Second, and more seriously, this is the wrong place for the local IM settings to be tweaked. IM should be looking at a local file in the user area that can persist through upgrades. As a representative StackOverflow report and discussion here noted, setting up a file in
.config/ImageMagick
does not work as expected. For example, "BUT you can't allow things that are disabled globally" (like restrictions on processing PDFs). There are some possible workarounds, but the documentation isn't clear about how all this works.The documentation on policy.xml should say clearly that settings should be NOT be changed in the global default copy of
policy.xml
, but in a local user copy ofpolicy.xml
. This is standard practice! Further, those local changes to settings should be respected by ImageMagick, even if the authors of IM think they are risky. Users are not children. The risks surrounding some setting changes should be clearly explained, and then the choice left to the users.The present situation, where every single upgrade is interrupted by a query about overwriting
policy.xml
is not tenable for the long run.Sincerely,
Dominik Wujastyk
Describe the solution you'd like
Follow the above recommendations.
The text was updated successfully, but these errors were encountered: