GNU bug report logs - #33587
[PROPOSED] Default to disabling ImageMagick

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 33587 in the body.
You can then email your comments to 33587 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: bug-gnu-emacs <at> gnu.org
Cc: Paul Eggert <eggert <at> Penguin.CS.UCLA.EDU>
Subject: [PROPOSED] Default to disabling ImageMagick
Date: Sun,  2 Dec 2018 10:09:19 -0800

From: Paul Eggert <eggert <at> Penguin.CS.UCLA.EDU>

ImageMagick has continuing stability and security problems, suggesting
that 'configure' should disable it by default.  See Glenn Morris's notes
at: https://lists.gnu.org/r/emacs-devel/2018-12/msg00036.html
* INSTALL, etc/NEWS: Mention this.
* configure.ac (imagemagick): Default to off.
---
 INSTALL      | 4 +++-
 configure.ac | 2 +-
 etc/NEWS     | 4 ++++
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/INSTALL b/INSTALL
index 0c56fff6d4..9696904dce 100644
--- a/INSTALL
+++ b/INSTALL
@@ -294,7 +294,9 @@ or more of these options:
   --without-gif          for GIF image support
   --without-png          for PNG image support
   --without-rsvg         for SVG image support
-  --without-imagemagick  for Imagemagick support
+
+Although ImageMagick support is disabled by default due to security
+and stability concerns, you can enable it with --with-imagemagick.
 
 Use --without-toolkit-scroll-bars to disable Motif or Xaw3d scroll bars.
 
diff --git a/configure.ac b/configure.ac
index 8b34c3b658..b70393925a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -354,7 +354,7 @@ AC_DEFUN
 OPTION_DEFAULT_ON([libsystemd],[don't compile with libsystemd support])
 OPTION_DEFAULT_OFF([cairo],[compile with Cairo drawing (experimental)])
 OPTION_DEFAULT_ON([xml2],[don't compile with XML parsing support])
-OPTION_DEFAULT_ON([imagemagick],[don't compile with ImageMagick image support])
+OPTION_DEFAULT_OFF([imagemagick],[compile with ImageMagick image support])
 OPTION_DEFAULT_ON([json], [don't compile with native JSON support])
 
 OPTION_DEFAULT_ON([xft],[don't use XFT for anti aliased fonts])
diff --git a/etc/NEWS b/etc/NEWS
index 6297d07879..07c6f74c44 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -37,6 +37,10 @@ functions 'json-serialize', 'json-insert', 'json-parse-string', and
 'json-parse-buffer' are typically much faster than their Lisp
 counterparts from json.el.
 
+** Emacs no longer defaults to using ImageMagick to display images,
+due to security and stability concerns.  To override the default, use
+'configure --with-imagemagick'.
+
 ** The etags program now uses the C library's regular expression matcher
 when possible, and a compatible regex substitute otherwise.  This will
 let developers maintain Emacs's own regex code without having to also
-- 
2.19.2

Message #8 received at 33587 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 33587 <at> debbugs.gnu.org, eggert <at> Penguin.CS.UCLA.EDU
Subject: Re: bug#33587: [PROPOSED] Default to disabling ImageMagick
Date: Sun, 02 Dec 2018 20:15:07 +0200

> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sun,  2 Dec 2018 10:09:19 -0800
> Cc: Paul Eggert <eggert <at> Penguin.CS.UCLA.EDU>
> 
> From: Paul Eggert <eggert <at> Penguin.CS.UCLA.EDU>
> 
> ImageMagick has continuing stability and security problems, suggesting
> that 'configure' should disable it by default.  See Glenn Morris's notes
> at: https://lists.gnu.org/r/emacs-devel/2018-12/msg00036.html
> * INSTALL, etc/NEWS: Mention this.
> * configure.ac (imagemagick): Default to off.

No objections from me, but let's please wait for a week, to let people
chance to voice objections.

Thanks.

Message #13 received at 33587 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 33587 <at> debbugs.gnu.org, Paul Eggert <eggert <at> Penguin.CS.UCLA.EDU>
Subject: Re: bug#33587: [PROPOSED] Default to disabling ImageMagick
Date: Sun, 02 Dec 2018 20:13:16 +0100

On Dez 02 2018, Paul Eggert <eggert <at> cs.ucla.edu> wrote:

> +** Emacs no longer defaults to using ImageMagick to display images,
> +due to security and stability concerns.  To override the default, use
> +'configure --with-imagemagick'.

ImageMagick is the only backend that supports scaling.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Message #16 received at 33587 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 33587 <at> debbugs.gnu.org, Paul Eggert <eggert <at> Penguin.CS.UCLA.EDU>
Subject: Re: bug#33587: [PROPOSED] Default to disabling ImageMagick
Date: Sun, 2 Dec 2018 15:51:57 -0800

Andreas Schwab wrote:
> ImageMagick is the only backend that supports scaling.

Good point, and if we make the change, the scaling issue should be mentioned in 
INSTALL. Perhaps something like the following wording:

"Although ImageMagick support is disabled by default due to security
and stability concerns, you can enable it by configuring with
--with-imagemagick.  ImageMagick is the only backend that supports
image scaling."

Message #19 received at 33587 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 33587 <at> debbugs.gnu.org
Subject: Re: bug#33587: [PROPOSED] Default to disabling ImageMagick
Date: Mon, 03 Dec 2018 14:08:29 -0500

I'm a bit surprised by the lack of objections so far, though it's early
days yet of course. Maybe it's an experiment that needs to be tried out
for the implications to be seen.

A related alternative would be to lower the priority of the ImageMagick
backend. At the moment, visiting eg a png image uses ImageMagick rather
than libpng if both are linked in.

Message #22 received at 33587 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 33587 <at> debbugs.gnu.org
Subject: Re: bug#33587: [PROPOSED] Default to disabling ImageMagick
Date: Mon, 3 Dec 2018 11:35:06 -0800

On 12/3/18 11:08 AM, Glenn Morris wrote:
> A related alternative would be to lower the priority of the ImageMagick
> backend. At the moment, visiting eg a png image uses ImageMagick rather
> than libpng if both are linked in.

If this alternative is taken and the user requests scaling, presumably 
the ImageMagick library would need to be used anyway since it can scale 
and libpng can't.

Message #25 received at 33587 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 33587 <at> debbugs.gnu.org
Subject: Re: bug#33587: [PROPOSED] Default to disabling ImageMagick
Date: Mon, 03 Dec 2018 14:40:10 -0500

Paul Eggert wrote:

> On 12/3/18 11:08 AM, Glenn Morris wrote:
>> A related alternative would be to lower the priority of the ImageMagick
>> backend. At the moment, visiting eg a png image uses ImageMagick rather
>> than libpng if both are linked in.
>
> If this alternative is taken and the user requests scaling, presumably
> the ImageMagick library would need to be used anyway since it can
> scale and libpng can't.

Sure. I mean, make use of ImageMagick require an explicit request, for
uses that might need those features (eww?), rather than just happening
by default like it does now.

Message #28 received at 33587 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 33587 <at> debbugs.gnu.org, Andreas Schwab <schwab <at> linux-m68k.org>,
 Paul Eggert <eggert <at> Penguin.CS.UCLA.EDU>
Subject: Re: bug#33587: [PROPOSED] Default to disabling ImageMagick
Date: Mon, 3 Dec 2018 21:09:17 +0000

On Sun, Dec 02, 2018 at 03:51:57PM -0800, Paul Eggert wrote:
> Andreas Schwab wrote:
> > ImageMagick is the only backend that supports scaling.
> 
> Good point, and if we make the change, the scaling issue should be mentioned
> in INSTALL. Perhaps something like the following wording:
> 
> "Although ImageMagick support is disabled by default due to security
> and stability concerns, you can enable it by configuring with
> --with-imagemagick.  ImageMagick is the only backend that supports
> image scaling."

FWIW the NS port on master supports scaling through the NS toolkit,
although there is the problem that most lisp code that wants to scale
checks exclusively for imagemagick support.
-- 
Alan Third

Message #31 received at 33587 <at> debbugs.gnu.org (full text, mbox):

From: David Engster <deng <at> randomsample.de>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 33587 <at> debbugs.gnu.org
Subject: Re: bug#33587: [PROPOSED] Default to disabling ImageMagick
Date: Tue, 04 Dec 2018 17:51:11 +0100

Glenn Morris writes:
> I'm a bit surprised by the lack of objections so far, though it's early
> days yet of course. Maybe it's an experiment that needs to be tried out
> for the implications to be seen.

Well, I do depend on image scaling, but I (like many others here, I
guess) build Emacs myself, so defaults don't matter much to me.

Question is: will disabling Imagemagick by default also have an impact
on how Emacs is shipped in distributions? I don't think so, at least as
long as they don't drop Imagemagick completely. If for instance Debian
has to take care of Imagemagick security issues anyway, why shouldn't
Emacs link to it?

But that's just my guess...

-David

Message #34 received at 33587 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: David Engster <deng <at> randomsample.de>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 33587 <at> debbugs.gnu.org
Subject: Re: bug#33587: [PROPOSED] Default to disabling ImageMagick
Date: Tue, 04 Dec 2018 12:00:48 -0500

David Engster wrote:

> Question is: will disabling Imagemagick by default also have an impact
> on how Emacs is shipped in distributions?

I don't know. It depends whether they go with the default configure
options or not.

> I don't think so, at least as long as they don't drop Imagemagick
> completely.

Note that Red Hat Enterprise Linux 8 _will_ drop ImageMagick completely
(though it will probably be available from an add-on repository),
presumably because they don't feel able to keep up with the security
issues. That's what prompted me to first raise this in

http://lists.gnu.org/r/emacs-devel/2018-12/msg00036.html

> If for instance Debian has to take care of Imagemagick security issues
> anyway, why shouldn't Emacs link to it?

(For reference:
https://security-tracker.debian.org/tracker/source-package/imagemagick )

Because one can never guarantee all security issues are fixed, and if a
project has a history of having a lot of them, it may be considered
likely to be insecure. Also there are the various Emacs crash reports
due to ImageMagick.

Message #37 received at 33587 <at> debbugs.gnu.org (full text, mbox):

From: David Engster <david <at> engster.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 33587 <at> debbugs.gnu.org
Subject: Re: bug#33587: [PROPOSED] Default to disabling ImageMagick
Date: Tue, 04 Dec 2018 18:38:59 +0100

Glenn Morris writes:
> Note that Red Hat Enterprise Linux 8 _will_ drop ImageMagick completely
> (though it will probably be available from an add-on repository),
> presumably because they don't feel able to keep up with the security
> issues. That's what prompted me to first raise this in
>
> http://lists.gnu.org/r/emacs-devel/2018-12/msg00036.html

RHEL can do this because they're supporting way less packages than other
distributions. As you know, enterprise customers have other priorities
than home desktop users. Debian cannot remove Imagemagick because many
other packages depend on it, at least currently.

>> If for instance Debian has to take care of Imagemagick security issues
>> anyway, why shouldn't Emacs link to it?
>
> (For reference:
> https://security-tracker.debian.org/tracker/source-package/imagemagick )
>
> Because one can never guarantee all security issues are fixed, and if a
> project has a history of having a lot of them, it may be considered
> likely to be insecure. Also there are the various Emacs crash reports
> due to ImageMagick.

I understand the reasoning. To me, image scaling is essential for what
I'm doing with Emacs, so I'm willing to take that risk. But that's just
one data point.

Don't get me wrong: I don't object to disable it by default. Let's see
what happens. Maybe distributions will then disable it as well, but they
have their own ways to see how changes like these affect users (by
having an 'unstable' tree or whatever).

-David

Message #40 received at 33587 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: David Engster <deng <at> randomsample.de>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 33587 <at> debbugs.gnu.org
Subject: Re: bug#33587: [PROPOSED] Default to disabling ImageMagick
Date: Tue, 04 Dec 2018 13:16:15 -0500

PS GraphicsMagick allegedly has fewer security issues than ImageMagick,
but https://debbugs.gnu.org/14358 saw no interest.

Message #43 received at 33587 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 33587 <at> debbugs.gnu.org
Cc: Glenn Morris <rgm <at> gnu.org>, Alan Third <alan <at> idiocy.org>,
 David Engster <david <at> engster.org>
Subject: Re: [PROPOSED] Default to disabling ImageMagick
Date: Mon, 10 Dec 2018 09:49:32 -0800

Elias Mårtenson wrote in 
<http://lists.gnu.org/r/emacs-devel/2018-12/msg00186.html> that image 
scaling via Xrender is surprisingly simple. So perhaps an X11 expert 
could investigate doing that for the X Window System, when ImageMagick 
scaling is not available or not used. My impression is that the Xrender 
extension (introduced in 2000) is reasonably popular among X11 servers 
these days.

Scaling on the server could also be faster (e.g., with hardware 
acceleration) and/or more reliable, so quite possibly it'd be better to 
use Xrender to scale even if ImageMagick is available.

Message #46 received at 33587 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Alan Third <alan <at> idiocy.org>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 33587 <at> debbugs.gnu.org, emacs-devel <at> gnu.org
Subject: Re: [PATCH v2] Add native image scaling (bug#33587)
Date: Thu, 10 Jan 2019 15:40:18 -0800

On 1/10/19 11:42 AM, Alan Third wrote:
> I’ve pushed this to master as‐is. If nobody else picks it up I’ll see
> if I can work out an ImageMagick fall‐back system.

Thanks for doing all that. I tweaked the indentation a bit to fit in 80 
columns etc.

At some point soon I plan to install the patch in Bug#33587#5, which 
would disable ImageMagick by default when configuring Emacs (you can 
still enable it if you like). On my Fedora 29 desktop this patch 
decouples Emacs from libMagickCore, libMagickWand, libfftw3 (the FFT 
library), libgomp (OpenMP), libtldl (libtool), and libXt (X toolkit), 
which shaves 5-10 ms off the Emacs startup time in my little experiments.

Message #51 received at 33587-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 33587-done <at> debbugs.gnu.org
Subject: Re: [PROPOSED] Default to disabling ImageMagick
Date: Mon, 13 May 2019 23:15:03 -0700

Paul Eggert wrote:

> At some point soon I plan to install the patch in Bug#33587#5

It wasn't soon, but I did install the patch just now. Closing the bug report.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.