Repository navigation
Replace Imagick with something better #13099
Description
EDIT (SEO): The PHP module "imagick" is not enabled although the theming app is. For favicon generation to work correctly, you need to install and enable this module.
A few days ago it was brought up to my attention that using Imagick could have very negative effects on security. The Nextcloud snap decided to not using it due to that fact, and I've now mitigated the same threat(s) as well by not using it in the Nextcloud VM.
Here are the discussion regarding the decision in the Nextcloud snap, and I think it totally makes sense not to use it in the Nextcloud Server as well.
The situation now though is that it's recomended and the setup checks will inform the user that the package is missing. As Nextcloud is advertising it's secure, then why use a package that is prune to a lot of CVEs in the past?
Regarding alternatives I think this post sums it up quite well.
Please consider removing the recommendation in future versions, and please also consider replacing the use of Imagick with something better and more secure.
EDIT 2: We now install Imaginary as a replacement for this in the Nextcloud VM.
Activity
kesselb commentedon Dec 16, 2018
Ref #12821
I see the concerns and could imagine to move the warning into the
themingapp that some feature are not working becauseimagickis not present.@skjnldsv @juliushaertl looks like @nextcloud/vm and @nextcloud/snap not going to add
imagick. @nextcloud/docker addedimagicka few days ago.Edit: There is already a warning that some things does not work:
server/apps/theming/templates/settings-admin.php
Line 136 in 3068f07
skjnldsv commentedon Dec 16, 2018
Nothing allow us to properly convert images types (especially svg) with php other than imagick (that I'm aware of) unfortunately.
kesselb commentedon Dec 16, 2018
Apart from this favicon svg generation the theming app works fine without
imagick?skjnldsv commentedon Dec 16, 2018
@danielkesselberg avatars will be not as great looking without imagick.
Previews too :)
J0WI commentedon Dec 17, 2018
How about the performance without
imagick?This does also affect the gallery app: https://github.com/nextcloud/gallery#supporting-more-media-types
cyphar commentedon Dec 17, 2018
From what I've read, most of the ImageMagick CVEs come from individual filters or filetypes that we probably don't care about -- is there a way to whitelist
policy.xmlso that we only allow the few formats that we want to support? In addition, checking that the magic header of files is actually correct (for the formats we want to support) would protect against most malicious files.ImageMagick (and GraphicsMagick to a lesser extent) have had quite a large number of CVEs, mostly due to the sheer amount of formats and features that users need to process images. I would say a good first step would be to figure out a whitelist hardening configuration that we can use across the board, and then we can evaluate switching away from ImageMagick if that's not sufficient.
J0WI commentedon Dec 17, 2018
See also Imagick/imagick#262
cyphar commentedon Dec 17, 2018
There are also a couple of ways we could restrict
ImageMagickthroughseccompor by putting it inside an empty network namespace (and a mount namespace which has everything mounted-over except/lib64and the file that is being accessed -- though this will require a bit of work since it requires having some sort ofunveilfeature).enoch85 commentedon Dec 17, 2018
@skjnldsv So something like https://github.com/flyimg/flyimg wouldn't work?
skjnldsv commentedon Dec 17, 2018
@enoch85 that would require shell_exec. Yes, we could rely on external software (like inkscape for example). But this is not really recommended to do on php. @rullzer ?
EDIT: sorry, I thought it was another software. Yes, we can use an external docker as well. We actually have a PoC somewhere for that. But this is a really heavy dependency and this would not scale to every setup. Also, most people don't use docker :/
kyrofa commentedon Dec 18, 2018
Thanks for this, @enoch85. It's probably no surprise that I completely agree on this issue. In the snap it's not even possible for people to use it, so folks will just see the warning forever and be unable to do anything. So at the very least, packagers should be able to disable this warning without triggering an integrity failure. Even better, Nextcloud should just stop suggesting it be installed if it's not. If one doesn't miss the functionality it provides, all it does is make the general populous less secure. Best yet: find an alternative so everyone can enjoy the functionality without trading security for it.
skjnldsv commentedon Dec 18, 2018
Let's be clear here, we all agree 😝
Having another php lib that could do the job would be ideal, but I don't have anything else to suggest unfortunately. I'm open to suggestion though :)
40 remaining items
[-]Don't use Imagick in server, and don't recommend it [/-][+]Replace Imagick with Graphicsmagick[/+]szaimen commentedon Jul 27, 2021
cc @nextcloud/server @nextcloud/security
J0WI commentedon Jul 27, 2021
Anyone familiar with libvips? The benchmarks and reviews look great.
tianon commentedon Jul 27, 2021
My experience with it was in the context of Ghost via "sharp" requiring too new of a libvips (Debian Buster has 8.7 and they required 8.9+) which caused a host of issues for getting it successfully installed, so I'd suggest surveying what version of libvips is available in the expected target environments and ensuring the lowest common denominator meets the needs of the project before committing (but that's just my 2c; no real stake here 😇).
[-]Replace Imagick with Graphicsmagick[/-][+]Replace Imagick with something better and[/+][-]Replace Imagick with something better and[/-][+]Replace Imagick with something better[/+]enoch85 commentedon Aug 1, 2021
I still think this is an ongoing discussion though.
Mainly this issue exist due to the security concerns, and whatever replacing Imagick needs to be better OR not produce a warning.
PVince81 commentedon Aug 2, 2021
also note: some research done with an external preview generator: #24166
(note: I don't have time right now to continue this, feel free to take over)
adripo commentedon Nov 13, 2021
While someone will continue developing this feature, what do you think if we proceed by marking the warning as INFO in the Administration Overview as suggested by @kerberizer in nextcloud/docker/1414#issuecomment-945842317?
WIP: Stop recommending imagemagick in the admin pages
solracsf commentedon Mar 19, 2022
Closing as per #24166
Fuseteam commentedon Mar 19, 2022
oh man, that's awesome