SVG corruption on download of local images

(Matthew Gaudet) #1

On our install, we ran into an issue where Download local images seems to have corrupted the image it downloads.

The link was ![Stitch](//

I can try hotlinking the image here to see if it reproduces on meta:


(Matthew Gaudet) #2

A separate related issue: If you revert to the hotlinked revision, the download local images job comes in and re-downloads. I’m wondering if maybe it shouldn’t.

(Rafael dos Santos Silva) #3

ImageMagick was bumped recently maybe it’s related?

(Eli the Bearded) #4

That’s the link to the bad one. It looks like the SVG has all of the parts, but every color has been turned into black. Well, more accurate might be all of the fill/stroke attributes appear to be stripped out.

(Jeff Atwood) #5

Here’s an uploaded version of (what I assume is?) the same svg image:

It looks like the process of uploading is breaking the file, somehow. You can run a diff on the original I found on wikipedia:

Doing so, it looks like removing linebreaks somehow busted this? The data appears the same, but everything has been moved to a single line rather than being multi-line? Can anyone verify my analysis is correct here?

(Eli the Bearded) #6

The wikipedia one has a <style> block with fill colors for each of the paths.

<style type="text/css">

Absent that, everything is just black.

(Rafael dos Santos Silva) #7

Yeah, the removal of the style block makes that happen. Easy to repro opening the original and disabling the styles on DevTools.

Style isn’t whitelisted here:

The question is: should it be, or it open another vector of attack?

Linking to a remote SVG breaks the image when it gets downloaded and fixed by system
(Kane York) #8

You can load URLs from CSS. With ImageMagick, this includes such URLs as file:/etc/passwd (not quite the right syntax, but you get the idea) etc etc.

We would need to get a CSS parser and sanitizer added to process the style contents.

(Jeff Atwood) closed #9