Image magic policy file in discourse git for non Docker installs


(Darix) #1

Continuing the discussion from ImageMagick CVE-2016–3714:

currently it is part of the docker image for people not using docker it would be easier to pick up from the base repository.


(cpradio) #2

If you aren’t using docker, you technically aren’t supported, but couldn’t you simply apply the policy.xml on your server and be done too?


(Darix) #3

sure. but imho this is the wrong place to store a file that every user needs compared to “just needed for docker”


(cpradio) #4

Well docker manages the imagemagick library… the discourse repo only contains the application code. So why would it exist there?


(Darix) #5

because it is a config file. and as i said … some people do not use docker


(Rafael dos Santos Silva) #6

But people who doesn’t use docker are on their own, since they choose a unsupported install right?


(cpradio) #7

For imagemagick, not Discourse specifically… (based on my understanding of the problem). So sticking it inside /discourse/ won’t do a single thing for you. You will still have to move it to its appropriate location.

Exactly.


(Régis Hanol) #8

@darix when you’re not using docker, you may have installed ImageMagick in billion different places depending on the sysadmin preferences and current mood. How can you expect Discourse to know where ImageMagick is installed? It’s a system dependency and we manage them using docker, so adding the configuration in the docker image definition is indeed the right place.


(Darix) #11

if you have the XML file … and i can pass the path to the imagemagick tools then i can make sure myself that the file is found. just as we did with the sRGB profile e.g. now i have to track yet another repository for changes which i should reflect in my rpm. while the proper solution would be having the file in the base repo.


(Sam Saffron) #13

This is not going our master repo, no point to carry it around, in a week or 2 I will rebuild our base image with a new image magick and get rid of the policy file.

I see no point in worrying about yet another spot to remove then just to cater for an unsupported install