search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
541 stars 48 forks source link

remove dependency on imagemagic #5009

Closed adrelanos closed 1 year ago

adrelanos commented 5 years ago

I don't see qubes-core-agent-linux make use of imagemagic. That's my conclusion from a simple grep.

qubes-app-linux-pdf-converter also depends on it. So perhaps qubes-core-agent-linux dependency on it is a leftover after a package split?

Also qubes-linux-utils depends on it.

But I nowhere see imagemagick being used.

It's also a deprecated, transitional package in Debian, not proving any required files as far as I can see.

apt-file list imagemagick
imagemagick: /usr/share/bug/imagemagick   
imagemagick: /usr/share/doc/imagemagick/NEWS.Debian.gz
imagemagick: /usr/share/doc/imagemagick/changelog.Debian.gz
imagemagick: /usr/share/doc/imagemagick/changelog.gz
imagemagick: /usr/share/doc/imagemagick/copyright

It depends on imagemagick-6.q16 but I don't see Qubes source code using any binaries provided by that package either.

unman commented 5 years ago

On Tue, Apr 30, 2019 at 03:06:27AM -0700, Patrick Schleizer wrote:

I don't see qubes-core-agent-linux make use of imagemagic. That's my conclusion from a simple grep.

qubes-app-linux-pdf-converter also depends on it. So perhaps qubes-core-agent-linux dependency on it is a leftover after a package split?

Also qubes-linux-utils depends on it.

But I nowhere see imagemagick being used.

It's also a deprecated, transitional package in Debian, not proving any required files as far as I can see.

apt-file list imagemagick
imagemagick: /usr/share/bug/imagemagick   
imagemagick: /usr/share/doc/imagemagick/NEWS.Debian.gz
imagemagick: /usr/share/doc/imagemagick/changelog.Debian.gz
imagemagick: /usr/share/doc/imagemagick/changelog.gz
imagemagick: /usr/share/doc/imagemagick/copyright

It depends on imagemagick-6.q16 but I don't see Qubes source code using any binaries provided by that package either.

Try grepping for "convert", provided by imagemagick - it's used in icon conversion, isnt it? Also, it's a dummy package: graphicsmagick-imagemagick-compat provides a drop in replacement.

adrelanos commented 5 years ago

More complex than I thought.

imagemagick is a security mess anyhow with (in Debian stable) unfixed security issues?

https://tracker.debian.org/pkg/imagemagick

66 security issues in jessie 7 security issues in sid 7 security issues in buster 61 security issues in stretch

(Thanks to @TNTBOMBOM for pointing that out.)

h01ger commented 5 years ago

On Sat, May 04, 2019 at 04:25:46AM -0700, Patrick Schleizer wrote:

https://tracker.debian.org/pkg/imagemagick

https://security-tracker.debian.org/tracker/source-package/imagemagick is the URL you (might not) want to look at ;)

-- tschau, Holger

           holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
marmarek commented 5 years ago

Try grepping for "convert", provided by imagemagick - it's used in icon conversion, isnt it?

Yes, icon format conversion. Either reading icon files from /usr/share/icons or similar location (which should come from authenticated packages), or to write pre-validated stream of raw RGBA values into a PNG file. So, none of its usage in qubes is exposed to untrusted data and security issues in imagemagick package do not directly affect qubes. But nevertheless, it may be a good idea to not force imagemagick installation, to avoid user using it accidentally.

Another horror story: commit messages - or rather lack of them in the source repository: https://github.com/ImageMagick/ImageMagick6/commits/master

Nurmagoz commented 4 years ago

any updates on this?

andrewdavidwong commented 4 years ago

So, none of its usage in qubes is exposed to untrusted data and security issues in imagemagick package do not directly affect qubes. But nevertheless, it may be a good idea to not force imagemagick installation, to avoid user using it accidentally.

In light of this, I've updated the issue type from bug to enhancement and am intentionally refraining from adding the security label.

h01ger commented 4 years ago

can graphicsmagick be used instead of imagemagick?

iamahuman commented 3 years ago

Related: #2397

jorgejones7711 commented 3 years ago

Any progress on this? Sure would be nice to have a small, clean gateway,

DemiMarie commented 1 year ago

Done.

adrelanos commented 1 year ago

Potential ticket flagging issue: This is more like a wontfix or invalid rather than done?

In a strictly technical way by looking at the title of this issue only "remove dependency on imagemagic" this was done but looking at the context of the ticket it wasn't done and might even be a regression.

What was the rationale for porting from imagemagick to graphicsmagick?

Using https://stackoverflow.com/questions/862051/what-is-the-difference-between-imagemagick-and-graphicsmagick as my source, quote:

Dependancies GraphicsMagick depends on 36 libraries whereas ImageMagick requires 64. Ref : http://www.graphicsmagick.org/1.3/FAQ.html

In terms of popularity...

ImageMagick questions on SO outnumber GraphicsMagick questions by a factor of 12:1 (7,375 questions vs 611 at May 2019), and ImageMagick followers on SO outnumber GraphicsMagick followers by 15:1 ((387 followers versus 25 at May 2019)

The summary of reasons for this bug report or feature request (depending on who is looking at it):

By changing from imagemagick to graphicsmagick the following result:

A) No enhancement?

Does not look better. Both, imagemagick and graphicsmagick have a long list of CVEs and unfixed security vulnerabilities according to above links.

Even if graphicsmagick list of CVEs was smaller, it could be argued it is due to lower popularity and not more secure design?

I haven't found other sources claiming that graphicsmagick is more secure than imagemagick.

B) Not addressed.

C) Regression since graphicsmagick might have more dependencies than imagemagick.

If graphicsmagick indeed has more dependencies than imagemagick and no security argument can be made for either, then I would even suggest to re-open this ticket and revert the port from graphicsmagick to imagemagick.

marmarek commented 1 year ago

Does not look better. Both, imagemagick and graphicsmagick have a long list of CVEs and unfixed security vulnerabilities according to above links.

Few stats based on exactly the links you provided:

ImageMagick:

GraphicsMagick:

For me it looks like a very significant improvement, especially when we consider how things look now (0 open issues in GM vs 18 in IM).

C) Regression since graphicsmagick might have more dependencies than imagemagick.

I think you got this backwards, earlier sentence reads:

Dependancies GraphicsMagick depends on 36 libraries whereas ImageMagick requires 64. Ref : http://www.graphicsmagick.org/1.3/FAQ.html

Nurmagoz commented 1 year ago

Is it possible to filter more of imagemagick dependencies? because i dont think its been removed entirely: 

user@host:~$ sudo apt remove --purge imagemagick*
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'imagemagick-6.q16hdri' for glob 'imagemagick*'
Note, selecting 'imagemagick' for glob 'imagemagick*'
Note, selecting 'imagemagick-common' for glob 'imagemagick*'
Note, selecting 'imagemagick-doc' for glob 'imagemagick*'
Note, selecting 'imagemagick-6-doc' for glob 'imagemagick*'
Note, selecting 'imagemagick-6.defaultquantum' for glob 'imagemagick*'
Note, selecting 'imagemagick-6.q16' for glob 'imagemagick*'
Note, selecting 'imagemagick-6-common' for glob 'imagemagick*'
Note, selecting 'imagemagick-6.q16' instead of 'imagemagick-6.defaultquantum'
Package 'imagemagick-6-doc' is not installed, so not removed
Package 'imagemagick-6.q16hdri' is not installed, so not removed
Package 'imagemagick-common' is not installed, so not removed
Package 'imagemagick-doc' is not installed, so not removed
The following packages were automatically installed and are no longer required:
  conntrack dconf-cli iptables keyboard-configuration libheif1 libip6tc2
  liblqr-1-0 libnetfilter-conntrack3 libnfnetlink0 libqubes-rpc-filecopy2
  libxfont2 python3-cffi-backend python3-daemon python3-dbus python3-lockfile
  python3-qubesdb python3-xcffib python3-xdg qubes-utils tinyproxy
  tinyproxy-bin x11-xkb-utils xauth xen-utils-4.14 xen-utils-common
  xen-utils-guest xenstore-utils xinit xserver-common xserver-xorg-core
  xserver-xorg-input-qubes xserver-xorg-qubes-common
  xserver-xorg-video-dummyqbs
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
  imagemagick* imagemagick-6-common* imagemagick-6.q16* libmagickcore-6.q16-6*
  libmagickwand-6.q16-6* qubes-core-agent* qubes-core-agent-networking*
  qubes-gui-agent* qubes-vm-dependencies*
0 upgraded, 0 newly installed, 9 to remove and 0 not upgraded.
After this operation, 10.7 MB disk space will be freed.
Do you want to continue? [Y/n]

These packages:

imagemagick-6-common
imagemagick-6.q16
libmagickcore-6.q16-6
libmagickwand-6.q16-6

still somehow dependent by qubes tools.

marmarek commented 1 year ago

Please note this change is included only in R4.2, it won't be backported to R4.1.