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

enable-zero-configuration and policy.xml #407

Closed
philtay opened this Issue Mar 21, 2017 · 19 comments

Comments

Projects
None yet
3 participants
@philtay

philtay commented Mar 21, 2017

Is there any way to embed a custom policy.xml at build time? If not, please consider this question as a feature request.

@mikayla-grace

This comment has been minimized.

Show comment
Hide comment
@mikayla-grace

mikayla-grace Mar 21, 2017

An interesting conundrum. A zero-configuration build that permits configuration. Why not use the default build that permits configuration if you want to honor the security policy. You can also include your policy in MagickCore/policy.c source module before you build. Not sure it makes sense to have a zero-configuration for all configuration files other than the security policy.

mikayla-grace commented Mar 21, 2017

An interesting conundrum. A zero-configuration build that permits configuration. Why not use the default build that permits configuration if you want to honor the security policy. You can also include your policy in MagickCore/policy.c source module before you build. Not sure it makes sense to have a zero-configuration for all configuration files other than the security policy.

@philtay

This comment has been minimized.

Show comment
Hide comment
@philtay

philtay Mar 21, 2017

An interesting conundrum. A zero-configuration build that permits configuration. Why not use the default build that permits configuration if you want to honor the security policy.

IMO enable-zero-configuration should mean zero configuration after build. For obvious reasons I must specify a security policy. The default one lacks several things I have to enforce. At the same time I don't want config files floating around after build.

You can also include your policy in MagickCore/policy.c source module before you build.

It sounds brittle. Do you mean I should edit a source file before each build? We're in a CI context and a sed on a semi-random file of a 3rd party project isn't very ideal.

Not sure it makes sense to have a zero-configuration for all configuration files other than the security policy.

It makes sense to give this opportunity for all config files, but policy.xml would be a great start for sure.

philtay commented Mar 21, 2017

An interesting conundrum. A zero-configuration build that permits configuration. Why not use the default build that permits configuration if you want to honor the security policy.

IMO enable-zero-configuration should mean zero configuration after build. For obvious reasons I must specify a security policy. The default one lacks several things I have to enforce. At the same time I don't want config files floating around after build.

You can also include your policy in MagickCore/policy.c source module before you build.

It sounds brittle. Do you mean I should edit a source file before each build? We're in a CI context and a sed on a semi-random file of a 3rd party project isn't very ideal.

Not sure it makes sense to have a zero-configuration for all configuration files other than the security policy.

It makes sense to give this opportunity for all config files, but policy.xml would be a great start for sure.

@mikayla-grace

This comment has been minimized.

Show comment
Hide comment
@mikayla-grace

mikayla-grace Mar 23, 2017

A robust solution eludes us given any solution must work cross-platform from Linux to Windows to an iPhone. To provide a workable solution, we will create a zero-configuration header file with all the configurations including the security policy. You can then copy it, edit it to reflect your local requirements, and replace it in the source tree before you compile IM with zero-configuration enabled. If you have a better suggestion that is cross-platform, let us know.

mikayla-grace commented Mar 23, 2017

A robust solution eludes us given any solution must work cross-platform from Linux to Windows to an iPhone. To provide a workable solution, we will create a zero-configuration header file with all the configurations including the security policy. You can then copy it, edit it to reflect your local requirements, and replace it in the source tree before you compile IM with zero-configuration enabled. If you have a better suggestion that is cross-platform, let us know.

@philtay

This comment has been minimized.

Show comment
Hide comment
@philtay

philtay Mar 23, 2017

Sure, the best way would be a ./configure flag (e.g. ./configure --security-policy=/path/to/policy.xml). Embed the specified file at compile-time and use it at run-time. This solution is applicable to all config files.

philtay commented Mar 23, 2017

Sure, the best way would be a ./configure flag (e.g. ./configure --security-policy=/path/to/policy.xml). Embed the specified file at compile-time and use it at run-time. This solution is applicable to all config files.

@philtay

This comment has been minimized.

Show comment
Hide comment
@philtay

philtay Mar 23, 2017

Another (unrelated) thing: the latest version of ImageMagick available on GitHub is 7.0.5-0. It looks like GitHub is out of sync.

philtay commented Mar 23, 2017

Another (unrelated) thing: the latest version of ImageMagick available on GitHub is 7.0.5-0. It looks like GitHub is out of sync.

@mikayla-grace

This comment has been minimized.

Show comment
Hide comment
@mikayla-grace

mikayla-grace Mar 23, 2017

We had considered your proposal previously but it fails the "robust cross-platform solution test." The zero-configuration header file we proposed works cross platform. However, your proposal is likely the cleanest approach to zero configuration so we will likely implement this solution within a few weeks.

Working on the Github issue, stand by.

mikayla-grace commented Mar 23, 2017

We had considered your proposal previously but it fails the "robust cross-platform solution test." The zero-configuration header file we proposed works cross platform. However, your proposal is likely the cleanest approach to zero configuration so we will likely implement this solution within a few weeks.

Working on the Github issue, stand by.

@philtay

This comment has been minimized.

Show comment
Hide comment
@philtay

philtay Mar 23, 2017

Very good. Hope to see it soon. A secure by default ImageMagick would be really great. Also: give to the user the opportunity to override the embedded policy. If a policy.xml can be found at run-time, it will prevail over the embedded one. In this way you shift away from you the security burden. Packagers can define a default secure policy which makes sense for their environment at build-time and, if some user is not happy with it, a standard policy.xml can still be used to replace the default.

philtay commented Mar 23, 2017

Very good. Hope to see it soon. A secure by default ImageMagick would be really great. Also: give to the user the opportunity to override the embedded policy. If a policy.xml can be found at run-time, it will prevail over the embedded one. In this way you shift away from you the security burden. Packagers can define a default secure policy which makes sense for their environment at build-time and, if some user is not happy with it, a standard policy.xml can still be used to replace the default.

@mikayla-grace

This comment has been minimized.

Show comment
Hide comment
@mikayla-grace

mikayla-grace Mar 24, 2017

After reconsidering your proposal for zero-configuration, the security policy must be compiled at build time suggesting the zero-configuration header file might be the best solution-- and its cross-platform. We set up a sample policy, you make custom edits, then build, then deploy. We can't readily convert a policy in XML to a "baked in" policy at build time.

mikayla-grace commented Mar 24, 2017

After reconsidering your proposal for zero-configuration, the security policy must be compiled at build time suggesting the zero-configuration header file might be the best solution-- and its cross-platform. We set up a sample policy, you make custom edits, then build, then deploy. We can't readily convert a policy in XML to a "baked in" policy at build time.

@philtay

This comment has been minimized.

Show comment
Hide comment
@philtay

philtay Mar 24, 2017

I don't understand why you need to "compile" and "convert" a policy. It's going to require a XML parser at build time. You should just embed the config file and use/parse it at run time. There are several ways to accomplish that. A quick search on the subject will reveal them. Two links to start:

http://stackoverflow.com/questions/4864866/c-c-with-gcc-statically-add-resource-files-to-executable-library
https://github.com/graphitemaster/incbin

philtay commented Mar 24, 2017

I don't understand why you need to "compile" and "convert" a policy. It's going to require a XML parser at build time. You should just embed the config file and use/parse it at run time. There are several ways to accomplish that. A quick search on the subject will reveal them. Two links to start:

http://stackoverflow.com/questions/4864866/c-c-with-gcc-statically-add-resource-files-to-executable-library
https://github.com/graphitemaster/incbin

@mikayla-grace

This comment has been minimized.

Show comment
Hide comment
@mikayla-grace

mikayla-grace Mar 24, 2017

The links describe methods that are not robustly cross platform. For example INCBIN says for Windows: "we ship a tool which can process source files containing INCBIN macro usage..." We're not interested in depending on external tools. We could have the XML as string inside a zero-configuration.h header file. but even then some compilers may choke if the XML exceeds certain limits such as 65535 characters. We will continue to research a robust cross-platform solution and try to find an optimal solution.

mikayla-grace commented Mar 24, 2017

The links describe methods that are not robustly cross platform. For example INCBIN says for Windows: "we ship a tool which can process source files containing INCBIN macro usage..." We're not interested in depending on external tools. We could have the XML as string inside a zero-configuration.h header file. but even then some compilers may choke if the XML exceeds certain limits such as 65535 characters. We will continue to research a robust cross-platform solution and try to find an optimal solution.

@philtay

This comment has been minimized.

Show comment
Hide comment
@philtay

philtay Jun 8, 2017

@mikayla-grace I saw you decided to adopt the header file method. We'd really like to use it but, unfortunately, we can't for the reasons explained above. Considering that we are currently using the C MagickWand API, the best for us would be to have the ability to set the policy at initialization time (i.e. immediately after MagickWandGenesis). Is there any plan to add a public facing method like MagickSetSecurity(char *domain, char *name, char *value) or similar?

philtay commented Jun 8, 2017

@mikayla-grace I saw you decided to adopt the header file method. We'd really like to use it but, unfortunately, we can't for the reasons explained above. Considering that we are currently using the C MagickWand API, the best for us would be to have the ability to set the policy at initialization time (i.e. immediately after MagickWandGenesis). Is there any plan to add a public facing method like MagickSetSecurity(char *domain, char *name, char *value) or similar?

@mikayla-grace

This comment has been minimized.

Show comment
Hide comment
@mikayla-grace

mikayla-grace Jun 8, 2017

Having a method to set a security policy is problematic because any user could then overwrite the policy defined by the distributor of the package. Many Linux systems, for example, set a security policy. A user can reduce certain policy restrictions but not increase them per the system security policy. Say a Linux instance sets the image width and height policy maximums to 4096. The system administrator would not want users to override the maximums with a call to MagickSetSecurity(). Its the same with the header methods, these are built in and cannot be changed. We recognize a user could download ImageMagick, set their own security policy, and build and execute, however, we cannot control this use case.

mikayla-grace commented Jun 8, 2017

Having a method to set a security policy is problematic because any user could then overwrite the policy defined by the distributor of the package. Many Linux systems, for example, set a security policy. A user can reduce certain policy restrictions but not increase them per the system security policy. Say a Linux instance sets the image width and height policy maximums to 4096. The system administrator would not want users to override the maximums with a call to MagickSetSecurity(). Its the same with the header methods, these are built in and cannot be changed. We recognize a user could download ImageMagick, set their own security policy, and build and execute, however, we cannot control this use case.

@philtay

This comment has been minimized.

Show comment
Hide comment
@philtay

philtay Jun 8, 2017

MagickSetSecurity should not override policy.xml, just complement it. The most restrictive settings shall always prevail. If policy.xml sets the max height to 4096 then MagickSetSecurity("resource", "height", "8192") should fail. The initial implementation could be even simpler: MagickSetSecurity succeeds only if the limit it tries to set is not enforced anywhere else, regardless of the value. For instance, if max height is set in policy.xml, then you can't alter this value using MagickSetSecurity.

Basically the use case we're trying to address is to let more "advanced" users to fully customize ImageMagick at build-time and/or run-time. To us ImageMagick is a library not a CLI and in our Docker container we don't even have an /etc directory to put configuration files into. It's just a statically linked self-contained binary. However we still need a security policy because it's a public facing microservice. More in general, I think there should be a way to securely ship and execute ImageMagick without depending on external resources.

philtay commented Jun 8, 2017

MagickSetSecurity should not override policy.xml, just complement it. The most restrictive settings shall always prevail. If policy.xml sets the max height to 4096 then MagickSetSecurity("resource", "height", "8192") should fail. The initial implementation could be even simpler: MagickSetSecurity succeeds only if the limit it tries to set is not enforced anywhere else, regardless of the value. For instance, if max height is set in policy.xml, then you can't alter this value using MagickSetSecurity.

Basically the use case we're trying to address is to let more "advanced" users to fully customize ImageMagick at build-time and/or run-time. To us ImageMagick is a library not a CLI and in our Docker container we don't even have an /etc directory to put configuration files into. It's just a statically linked self-contained binary. However we still need a security policy because it's a public facing microservice. More in general, I think there should be a way to securely ship and execute ImageMagick without depending on external resources.

@mikayla-grace

This comment has been minimized.

Show comment
Hide comment
@mikayla-grace

mikayla-grace Jun 8, 2017

Have you looked @ the --disable-installed option? With this option, the user can set the policy in ~/.config/ImageMagick/policy.xml-- and the system policy is not consulted. The downside is the administrator cannot override the users policy.

Your "simple" implementation of MagickSetSecurity() may work. We could implement that but only if the --disable-installed option does not meet your expectations. Let us know.

mikayla-grace commented Jun 8, 2017

Have you looked @ the --disable-installed option? With this option, the user can set the policy in ~/.config/ImageMagick/policy.xml-- and the system policy is not consulted. The downside is the administrator cannot override the users policy.

Your "simple" implementation of MagickSetSecurity() may work. We could implement that but only if the --disable-installed option does not meet your expectations. Let us know.

@philtay

This comment has been minimized.

Show comment
Hide comment
@philtay

philtay Jun 8, 2017

First of all, thanks for the quick reply and for your help.

In the Docker image there isn't a ~/ directory, not even a filesystem hierarchy. We use scratch as base image. This is a common pattern when you ship a single statically linked executable. The application is written in Go and we use CGO to invoke the MagickWand API.

In our case having something like MagickSetSecurity is a clear win and I think that a lot of MagickWand wrappers out there will end up using it (e.g. PHP, Python, etc.). Many of them are web oriented, a context where security is paramount. The authors of these wrappers will have the opportunity to provide "secure-by-default" libraries to their users. They could also give them the possibility to tweak the security settings directly in their favorite language (Python, Ruby, etc.).

philtay commented Jun 8, 2017

First of all, thanks for the quick reply and for your help.

In the Docker image there isn't a ~/ directory, not even a filesystem hierarchy. We use scratch as base image. This is a common pattern when you ship a single statically linked executable. The application is written in Go and we use CGO to invoke the MagickWand API.

In our case having something like MagickSetSecurity is a clear win and I think that a lot of MagickWand wrappers out there will end up using it (e.g. PHP, Python, etc.). Many of them are web oriented, a context where security is paramount. The authors of these wrappers will have the opportunity to provide "secure-by-default" libraries to their users. They could also give them the possibility to tweak the security settings directly in their favorite language (Python, Ruby, etc.).

@mikayla-grace

This comment has been minimized.

Show comment
Hide comment
@mikayla-grace

mikayla-grace Jun 10, 2017

We propose a simple MagickSetSecurityPolicy() method that accepts a single parameter, an XML string with the security policy per https://www.imagemagick.org/script/security-policy.php. The policy is only applied if the security policy has not already been set and of course if the XML parses. As you know, when it comes to security, simple is desirable. Best practices requires that this method is called right after MagickCoreGenesis().

mikayla-grace commented Jun 10, 2017

We propose a simple MagickSetSecurityPolicy() method that accepts a single parameter, an XML string with the security policy per https://www.imagemagick.org/script/security-policy.php. The policy is only applied if the security policy has not already been set and of course if the XML parses. As you know, when it comes to security, simple is desirable. Best practices requires that this method is called right after MagickCoreGenesis().

@philtay

This comment has been minimized.

Show comment
Hide comment
@philtay

philtay Jun 10, 2017

I like it. +1

Only a question: will MagickSetSecurityPolicy work if the enable-zero-configuration flag is set? It looks like that a default policy is automatically specified in zero-configuration mode.

philtay commented Jun 10, 2017

I like it. +1

Only a question: will MagickSetSecurityPolicy work if the enable-zero-configuration flag is set? It looks like that a default policy is automatically specified in zero-configuration mode.

dlemstra pushed a commit that referenced this issue Jun 10, 2017

dlemstra pushed a commit that referenced this issue Jun 10, 2017

@mikayla-grace

This comment has been minimized.

Show comment
Hide comment
@mikayla-grace

mikayla-grace Jun 10, 2017

Good point. Fixed. Building a Beta release now with the latest patches.

mikayla-grace commented Jun 10, 2017

Good point. Fixed. Building a Beta release now with the latest patches.

@philtay

This comment has been minimized.

Show comment
Hide comment
@philtay

philtay Jun 12, 2017

Thank you

philtay commented Jun 12, 2017

Thank you

@philtay philtay closed this Jun 12, 2017

netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this issue Jun 14, 2017

he
Updated ImageMagick to 7.0.6.0.
2017-06-10  7.0.6-0 Cristy  <quetzlzacatenango@image...>
  * Release ImageMagick version 7.0.6-0, GIT revision 20194:b0c0d00:20170611.

2017-06-10  7.0.6-1 Glenn Randers-Pehrson <glennrp@image...>
  * coders/png.c: Accept exIf chunks whose data segment
    erroneously begins with "Exif\0\0".

2017-06-10  7.0.6-0 Cristy  <quetzlzacatenango@image...>
  * Introduce SetMagickSecurityPolicy() (MagickCore) and
    MagickSetSecurityPolicy() (MagickWand) to set the ImageMagick security
    policy (reference ImageMagick/ImageMagick#407).

2017-06-02  7.0.5-10 Cristy  <quetzlzacatenango@image...>
  * Release ImageMagick version 7.0.5-10, GIT revision 20155:38ebc02:20170602.

2017-06-01  7.0.5-10 Glenn Randers-Pehrson <glennrp@image...>
  * Removed experimental PNG zxIF chunk support; the proposal is dead.

2017-06-01  7.0.5-10 Cristy  <quetzlzacatenango@image...>
  * Fix choppy bitmap font rendering (reference
    https://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=32071).
  * The +opaque option is not longer a noop (reference
    https://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=32081).
  * Add support  for 'hex:' property.

netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this issue Jun 14, 2017

he
Upgrade to ImageMagick6 version 6.9.8-10.
Upstream changes:

2017-06-10  6.9.8-10 Cristy  <quetzlzacatenango@image...>
  * Release ImageMagick version 6.9.8-10, GIT revision 11637:eb6f363:20170610.

2017-06-10  6.9.8-10 Cristy  <quetzlzacatenango@image...>
  * Introduce SetMagickSecurityPolicy() (MagickCore) and
    MagickSetSecurityPolicy() (MagickWand) to set the ImageMagick security
    policy (reference ImageMagick/ImageMagick#407).

2017-06-02  6.9.8-9 Cristy  <quetzlzacatenango@image...>
  * Release ImageMagick version 6.9.8-9, GIT revision 11625:91bb35e:20170602.

2017-06-02  6.9.8-9 Cristy  <quetzlzacatenango@image...>
  * Fix choppy bitmap font rendering (reference
    https://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=32071).
  * Add support for 'hex:' property.

2017-05-28  6.9.8-8 Cristy  <quetzlzacatenango@image...>
  * Release ImageMagick version 6.9.8-8, GIT revision 11606:8b67333:20170528.

2017-05-28  6.9.8-8 Cristy  <quetzlzacatenango@image...>
  * Transient error validating the JPEG-2000 image format (reference
    ImageMagick/ImageMagick#501).
  * Properly allocate DCM image colormap (reference
    https://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=32063).

2017-05-26  6.9.8-7 Cristy  <quetzlzacatenango@image...>
  * Release ImageMagick version 6.9.8-7, GIT revision 11598:07d1dee:20170526.

2017-05-23  6.9.8-7 Cristy  <quetzlzacatenango@image...>
  * Improper allocation of memory for IM instances without threads (reference
          ImageMagick/ImageMagick#497).
  * Delete corrupt image from list (reference
    ImageMagick/ImageMagick#500).

2017-05-19  6.9.8-6 Cristy  <quetzlzacatenango@image...>
  * Release ImageMagick version 6.9.8-6, GIT revision 11590:7ce2d38:20170519.

2017-05-15  6.9.8-6 Cristy  <quetzlzacatenango@image...>
  * Support various image operators for the compare utility (reference
    https://www.imagemagick.org/discourse-server/viewtopic.php?f=2&t=31938).

jsonn pushed a commit to jsonn/pkgsrc that referenced this issue Jun 14, 2017

he
Updated ImageMagick to 7.0.6.0.
2017-06-10  7.0.6-0 Cristy  <quetzlzacatenango@image...>
  * Release ImageMagick version 7.0.6-0, GIT revision 20194:b0c0d00:20170611.

2017-06-10  7.0.6-1 Glenn Randers-Pehrson <glennrp@image...>
  * coders/png.c: Accept exIf chunks whose data segment
    erroneously begins with "Exif\0\0".

2017-06-10  7.0.6-0 Cristy  <quetzlzacatenango@image...>
  * Introduce SetMagickSecurityPolicy() (MagickCore) and
    MagickSetSecurityPolicy() (MagickWand) to set the ImageMagick security
    policy (reference ImageMagick/ImageMagick#407).

2017-06-02  7.0.5-10 Cristy  <quetzlzacatenango@image...>
  * Release ImageMagick version 7.0.5-10, GIT revision 20155:38ebc02:20170602.

2017-06-01  7.0.5-10 Glenn Randers-Pehrson <glennrp@image...>
  * Removed experimental PNG zxIF chunk support; the proposal is dead.

2017-06-01  7.0.5-10 Cristy  <quetzlzacatenango@image...>
  * Fix choppy bitmap font rendering (reference
    https://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=32071).
  * The +opaque option is not longer a noop (reference
    https://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=32081).
  * Add support  for 'hex:' property.

jsonn pushed a commit to jsonn/pkgsrc that referenced this issue Jun 14, 2017

he
Upgrade to ImageMagick6 version 6.9.8-10.
Upstream changes:

2017-06-10  6.9.8-10 Cristy  <quetzlzacatenango@image...>
  * Release ImageMagick version 6.9.8-10, GIT revision 11637:eb6f363:20170610.

2017-06-10  6.9.8-10 Cristy  <quetzlzacatenango@image...>
  * Introduce SetMagickSecurityPolicy() (MagickCore) and
    MagickSetSecurityPolicy() (MagickWand) to set the ImageMagick security
    policy (reference ImageMagick/ImageMagick#407).

2017-06-02  6.9.8-9 Cristy  <quetzlzacatenango@image...>
  * Release ImageMagick version 6.9.8-9, GIT revision 11625:91bb35e:20170602.

2017-06-02  6.9.8-9 Cristy  <quetzlzacatenango@image...>
  * Fix choppy bitmap font rendering (reference
    https://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=32071).
  * Add support for 'hex:' property.

2017-05-28  6.9.8-8 Cristy  <quetzlzacatenango@image...>
  * Release ImageMagick version 6.9.8-8, GIT revision 11606:8b67333:20170528.

2017-05-28  6.9.8-8 Cristy  <quetzlzacatenango@image...>
  * Transient error validating the JPEG-2000 image format (reference
    ImageMagick/ImageMagick#501).
  * Properly allocate DCM image colormap (reference
    https://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=32063).

2017-05-26  6.9.8-7 Cristy  <quetzlzacatenango@image...>
  * Release ImageMagick version 6.9.8-7, GIT revision 11598:07d1dee:20170526.

2017-05-23  6.9.8-7 Cristy  <quetzlzacatenango@image...>
  * Improper allocation of memory for IM instances without threads (reference
          ImageMagick/ImageMagick#497).
  * Delete corrupt image from list (reference
    ImageMagick/ImageMagick#500).

2017-05-19  6.9.8-6 Cristy  <quetzlzacatenango@image...>
  * Release ImageMagick version 6.9.8-6, GIT revision 11590:7ce2d38:20170519.

2017-05-15  6.9.8-6 Cristy  <quetzlzacatenango@image...>
  * Support various image operators for the compare utility (reference
    https://www.imagemagick.org/discourse-server/viewtopic.php?f=2&t=31938).

clrpackages pushed a commit to clearlinux-pkgs/ImageMagick that referenced this issue Jul 17, 2017

Ikey Doherty
ImageMagick: Autospec creation for update from version 7.0.5.3 to ver…
…sion 7.0.6.0

2017-06-10  7.0.6-0 Cristy  <quetzlzacatenango@image...>
  * Introduce SetMagickSecurityPolicy() (MagickCore) and
    MagickSetSecurityPolicy() (MagickWand) to set the ImageMagick security
    policy (reference ImageMagick/ImageMagick#407).

2017-06-02  7.0.5-10 Cristy  <quetzlzacatenango@image...>
  * Release ImageMagick version 7.0.5-10, GIT revision 20155:38ebc02:20170602.

2017-06-01  7.0.5-10 Glenn Randers-Pehrson <glennrp@image...>
  * Removed experimental PNG zxIF chunk support; the proposal is dead.

2017-06-01  7.0.5-10 Cristy  <quetzlzacatenango@image...>
  * Fix choppy bitmap font rendering (reference
    https://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=32071).
  * The +opaque option is not longer a noop (reference

(NEWS truncated at 15 lines)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment