1. 8
  1.  

  2. 1

    I don’t understand why the author suggests that distributions often don’t update ImageMagick. Do they not know that security fixes get backported to stable repositories? I find that surprising given that they’re clearly quite competent.

    I’m also curious if GraphicsMagick is affected. I looked on their news page, but the most recent release doesn’t mention the CVE number (I just did a Find). But maybe it’s just that no one looked.

    1. -2

      If you’re running ImageMagick this decade you’re doing things horribly wrong.

      1. 13

        I’m not sure what people would use instead.

        1. 2

          If you have a codebase using IM and you don’t want to rewrite it, the first quick fix to come to mind is to use some other library with a safer parser to decode the incoming images. Then pass something to IM which requires no parsing or trivial parsing, like a pointer to the decoded pixels in memory or a PNM.

          Using ImageMagick for input parsing is scary. Using it for output isn’t.

          1. 2

            The stb libraries are very good if you have simple requirements:

            stb_image

            stb_image_write

            stb_image_resize

            1. 0

              libpng if you want to handle PNGs, libjpeg if you want to handle JPEGs.

              1. 11

                Neither of those libraries is particularly adept at rescaling images.

                1. 1

                  If you need basic image manipulation you should use something like gdk-pixbuf. I used it years ago but I’ve heard from people using it large scale production today.

                2. 1

                  Uhhh

              2. 1

                Is the GraphicsMagick fork good?

                1. 3

                  I assume not. The goal of being able to handle every format under the sun turns out to be (a) hard to implement securely and (b) not to line up well with actual requirements of actual software for actual users.