README rendering doesn't handle relative/local SVG images

[stuartpb]

See https://github.com/litl-license/litl-license/tree/e50196aa3dba3f667728483eb801022d9c113925 - I had to switch the inline image here to PNG for it to display on GitHub, which is lame and means that it's going to look lousy on Retina displays. (I would later go on to fix this by passing it through a gh-pages URL, which gives the added benefit of the code working when copied to repos that don't have this image.)

[cirosantilli]

SVG does not work from READMEs by design for security concerns: http://stackoverflow.com/a/21521184/895245

Interestingly, however, it seems that is has started to show on blob show: https://github.com/blog/1902-svg-viewing-diffing https://github.com/cirosantilli/test/blob/master/svg.svg , so maybe this request might be accepted now?

[stuartpb]

SVG does not work from READMEs by design for security concerns

Putting the security angle aside for a moment, SVGs totally do work in READMEs: it's how shields.io does badges (h5bp/lazyweb-requests#150), along with other services like Gitter.

This is a bug, one that is only present for SVG files relative to the README in the repository. The bug is caused (as far as I can tell, with a tip of the hat to Karsten S.) by the Markdown renderer rewriting remote URLs to point to rehosted images at camo.githubusercontent.com (which handles SVG's content-type correctly), but directing local urls to a route that points to raw.githubusercontent.com (which serves SVG files as text/plain with a header coercing the browser not to interpret it as SVG).

The solution should be to fix raw.githubusercontent.com to handle SVGs the same way as it handles other images (serving them with the appropriate content-type), or (if that's unfeasible) to have the Markdown render path rewrite local SVG references to rehost and point to camo.githubusercontent.com (as it currently does for remote images).

(edited 2017-07-23 to bold the line with the solution for anybody coming in from github/markup#556)

---

Coming back to the security question, there's no actual security problem to displaying SVGs. As the links on that question mention, SVG images don't run scripts, and even if they did, it would be in a sandboxed document no more dangerous than visiting the image separately/in an iframe.

[stuartpb]

Regarding fixing raw.githubusercontent.com: X-Content-Type-Options: nosniff is a half-assed measure against hotlinking that breaks hotlinking for files only when the content-type is incorrect. raw.githubusercontent.com doesn't get the content-type wrong for raster images, so they hotlink just fine, even though breaking <img> was half of the rationale given for implementing nosniff. GitHub complained about people using raw.githubusercontent.com as a CDN due to it being implemented as a Rails view with poor performance; the solution should have been to rewrite raw.githubusercontent.com to not go through Rails, not to rely on bugs and some headers that make it coincidentally bad for some use cases.

If GitHub has a problem with raw.githubusercontent.com having bad performance as a CDN, the fix is staring them right in the face: put it on the deployment system gh-pages uses (#212), minus the Jekyll rendering step. This is how people are already working around this problem (I've even renamed my master branch to gh-pages on projects I even remotely might want to include files from).

[stuartpb]

On 12/19/2014 8:34 AM, GitHub Staff wrote:

Hi Stuart,

Thanks for your feedback! I can understand your frustration. I have added your feedback to our list for our team to consider.

[GreLI]

What security concerns are you talking about? Browsers are already disabling scripting and other security-related SVG features in an <img> tag. See for example SVG as an Image on MDN.

[stuartpb]

@GreLI That's what I said:

Coming back to the security question, there's no actual security problem to displaying SVGs. As the links on that question mention, SVG images don't run scripts, and even if they did, it would be in a sandboxed document no more dangerous than visiting the image separately/in an iframe.

[drewnoakes]

A workaround for others hitting this issue from a search engine (as I did) is to use the cdn.rawgit.com service.

Before:
https://raw.githubusercontent.com/zeromq/netmq/master/docs/Images/NetMQLogo.svg

After:
https://cdn.rawgit.com/zeromq/netmq/master/img/NetMQLogo.svg

[ioquatix]

+1

[stuartpb]

I was going to close this, but github/markup#556 (comment) suggests it's still an issue.

[gucu112]

@stuartpb #556 was closed recently and I believe it is not an issue anymore.

[FranklinYu]

I think this issue can be closed. Embedding SVG in Markdown is officially supported by GitHub. If there is still any issue, it would be considered bug instead of lack of feature, so user should report in https://github.com/github/markup.

[TPS]

Per above & https://stackoverflow.com/a/16462143, this is solved