Fix relative SVG rendering
ioquatix opened this issue · 90 comments
As discussed in isaacs/github#316
Essentially embedding SVG images into a README.md file doesn't work but probably should. It's apparently broken due to the content type being incorrect for the SVG file being served.
+1
👍
👍
+1
👍
Wow, has this really been a bug for over a year?
@dangnelson No, I don't think they even regard it as an issue. This is probably a "won't fix".
This isn't an issue with the Markup gem itself, but it certainly is a valid bug. Looking into a resolution now.
@ioquatix: we're discussing it currently! The biggest issue we need to overcome is security due to JS execution in SVG — allowing user-controlled scripts on a GitHub domain could be dangerous — so we're considering strategies to work in out. It might take a bit to get it fully ironed out, but I'm pushing this forward internally, so I'll let you know when there's any updates.
@kivikakk I thought that might be a problem. I'm glad you are thinking about it. The content is served from a raw.github.io right? What about using something like https://content-security-policy.com to protect your main domain?
Unfortunately not yet; there's been a lot going on. We are still pushing forward with the issue (lots of moving parts), but slowly.
@kivikakk Perhaps this is a stupid comment/suggestion, and I understand what your are saying, but then how come SVG previews already work in this context? https://github.com/ioquatix/build-dependency/blob/master/partial.svg
@ioquatix when rendering a full blob, we use our internal "Render" system, which does sandboxed content rendering. Because it can take some time, there's also AJAX and a bunch of other things involved. (e.g. here's the actual path to the SVG renderer) This would look super ugly if used inline (all those AJAX spinners ...), and because it depends on an <iframe> for sandboxing, getting the width/height to propagate would be super awkward.
So we're looking into a solution that doesn't require using Render while still providing adequate security. (Currently thinking of sanitising the SVG ourselves, or a solution involving randomised subdomain names for each request to prevent cross-tab JS access.)
Oh, thanks for the awesome explanation.
That makes sense.
Well, I'm glad you are working on it and I'm certainly looking forward to be able to use SVG in my documentation/README :)
Relates to #270 , because SVGs can be Base64-encoded.
@kivikakk Sorry, just my monthly check for updates - how are things progressing? I'm still looking forward to putting SVG into my README.md - what about simply sanitising all scripts from the SVG?
@ioquatix No need to say sorry! Good timing, as I'm literally working on a means of fixing this right this very second (!). I'm taking a whitelist-the-SVG-elements approach — the hardest bit is hooking this all into our raw file serving infrastructure, as it's extensively tuned and therefore not the easiest thing to integrate an XML sanitiser into. I'll be sure to update here when I've got something public facing going!
I've been looking into SVG files w.r.t security and would love to hear your input on this. If you consider 3 cases of issues with SVGs,
(1) SVGs containing javascript code
If you're not including the <svg> tags directly in the generated html you should be OK here. In markdown you can say  and this would typically render in HTML as <img src="https://myevilsite.com/badsvg.svg>. Since you've specified the SVG file as the src of IMG tag, no script execution takes place. https://www.w3.org/wiki/SVG_Security and https://developer.mozilla.org/en-US/docs/Web/SVG/SVG_as_an_Image have more info on this.
(2) SVGs containing billion laughs payload - Client side DOS attack
In markdown you can say  and this would typically render in HTML as <img src="https://myevilsite.com/badsvg.svg>. Now I can have myevilsite.com serve billion-laughs payload in the SVG that looks like this,
I've observed that this makes the tab hang in Chrome because they won't fixed https://bugs.chromium.org/p/chromium/issues/detail?id=617891
But this does not break Firefox/Edge/IE because they seem to have entity expansion limits and stop after a while. Your webpage will remain responsive. You can even see a console message in Edge/IE that looks like,
(3) Well formed SVGs which make your browser run out of resources (a slight variation of 2)
As commented by pdr @ https://bugs.chromium.org/p/chromium/issues/detail?id=617891, you can construct a well formed SVG that still does client side DOS like below,
(3) makes the tab crash on all browsers (tested on Chrome/Firefox/IE/Edge)
So as far as SVG script execution and XSS are concerned, you're relatively safe as long as you're rendering the SVG within an IMG tag. (2) can be gotten rid of by sanitizing the SVG and ensuring we do not support expansion of entities, like someone suggested we can even go the white-listing route and sanitize <!ENTITY> elements within an SVG.
But what do we do about (3)?
@pkuma-msft wrote:
But what do we do about (3)?
Initial thoughts...
Option 1
Require the SVG to be embedded, rather than simply linked. Then limit the number of elements served, displaying a warning instead if the number of elements is above a safe threshold.
Option 2
Consider this to be not GitHub's problem and rely on browser vendors to fix it.
Conclusion
Until browser vendors start fixing this, option 1 is probably best 😞
I believe it should be browser's job. Browser knows best how much resource is available locally.
It is unfortunate that Chrome is pushing us to option 1.
For the majority of use cases, using <img> tag seems like a good way forward. It's not the responsibility of GitHub to fix browsers, and in any case, it's probably simply not possible.
@kivikakk, re #556 (comment):
The biggest issue we need to overcome is security due to JS execution in SVG — allowing user-controlled scripts on a GitHub domain could be dangerous — so we're considering strategies to work in out.
As I pointed out the last time GitHub said this, two and a half years ago, there's no reason to complicate the code path, since <script> tags are not executed in SVG images as included via <img>, as can be seen in the numerous SVG images that GitHub Markdown already displays when URLs are not specified relative to the repository, such as this one right here:
Please, just... read this comment from that issue. Please. I'm losing my mind having to re-explain this basic point every few years, with nothing coming of it every separate time.
I'm going to specifically copy-paste the bottom-line takeaway from that comment to this thread (you can read the full explanation over at isaacs/github#316):
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).
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)
This is the correct solution, and the one that should be done.
@kivikakk perhaps you can give an update taking into consideration the above comments regarding inline SVG <img> tags?
@ioquatix @stuartpb Thanks for your submissions!
Even if browsers deny execution via <img>, there's still the problem that a user can simply get linked to an SVG file directly, and thus cause script execution on a GitHub-controlled domain. We don't want any code execution from uploaded content, understandably, and so this isn't a solution.
@kivikakk Isn't that already an issue since I can open https://camo.githubusercontent.com/50f5ad81a6aacaa37cdbd187c32ae493607843bb/68747470733a2f2f75706c6f61642e77696b696d656469612e6f72672f77696b6970656469612f636f6d6d6f6e732f662f66642f47686f73747363726970745f54696765722e737667 in a new browser window and it's the SVG document?
You can, but that's on the camo host and subdomain. We don't serve GitHub user content through camo. We're trying to prevent compromise of raw.githubusercontent.com since that may have private data open (i.e. you can view a private repo's contents there) and we don't want script execution on that domain accordingly.
Okay, then how about plan B, having the Markdown render path rewrite local repo image references, instead of pointing them to raw.githubusercontent.com, to point to the image on camo.githubusercontent.com (following the same code path as is currently used to rehost remote images)? I imagine this'd also yield some degree of performance buff anyway as camo, as I understand it, is better configured to serve static blob assets than raw.
@stuartpb For reasons already covered (e.g. (a) "We don't serve GitHub user content through camo", (b) camo would have to fetch it from raw anyway in the first place, so this is strictly a performance regression), this is not a solution. I'm already working on a definitive solution to this which gels with our wider infrastructure in my downtime between other tasks, as referenced in earlier comments.
@kivikakk, I appreciate your work on this, as, I'm sure, do others in the thread. Thanks for taking this on :)
Your two most recent comments initially left me confused. The first of these, in particular, appeared to contradict some other remarks. I now think I have found an interpretation of your comments that resolves these my confusion. I'll unpack that here, and I would be grateful if you could confirm whether my present understanding is correct. If so, then I hope my post will help others who were initially as puzzled as I was!
Source of confusion
Initial premise
You wrote:
allowing user-controlled scripts on a GitHub domain could be dangerous
An unstated premise here is that GitHub, Inc., trusts its own client-side scripts enough to want them to run in visitors' browsers when visiting *.github.com domains (at least, in those browsers where JavaScript is supported and enabled).
But GitHub, Inc., understandably, does not trust its users to the same extent, and therefore wants user-generated client-side scripts not to run under those same circumstances.
So far, this is all fair enough. (At least, it is if we put aside the case of *.github.io. I think the latter is outside the scope of what you meant by "a GitHub domain" in your remark above.)
Apparent contradiction 1
Subsequently, you implied that it is not a problem for users to run user-generated scripts "on the camo host and subdomain", even if embedded into content within github.com such as @stuartpb's comment. This appears to contradict your remark quoted above.
Apparent contradiction 2
In the same comment, you also said:
We don't serve GitHub user content through camo.
This seems to contradict a GitHub Help article, which says:
To host [user-uploaded] images, GitHub uses the open-source project Camo. Camo generates an anonymous URL proxy for each image that starts with
https://camo.githubusercontent.com/and hides your browser details and related information from other users.
Puzzlement 1
Again in the same comment, you said:
We're trying to prevent compromise of
raw.githubusercontent.comsince that may have private data open (i.e. you can view a private repo's contents there) and we don't want script execution on that domain accordingly.
This is the first time in this thread that the exposure of private repositories has been mentioned as a concern. Is this the danger you were referring to in the first comment above? If so, then that was not obvious to me, nor perhaps to other readers of the thread.
Puzzlement 2
The soundness of your objection to @stuartpb's suggestion was not immediately clear.
Resolving the confusion
I guess that what you meant above by "GitHub user content" is not "content provided by GitHub users" but rather, "content provided by GitHub users and hosted (not merely proxied) by GitHub within *.github.com".
I also guess that when you said "allowing user-controlled scripts on a GitHub domain could be dangerous", rather than being especially concerned about malicious vectors like those @pkuma-msft highlighted, you were primarily concerned with a different and quite specific vector. This vector is that Mallory might upload a client-side script to raw.githubusercontent.com that would, if Alice runs it, make Alice's browser siphon data from Alice's private GitHub account to Mallory's server. Same-origin policies would not protect Alice here because Alice's private data would also be being served by raw.githubusercontent.com.
If so, this resolves apparent contradictions 1 and 2, and puzzlement 1.
Finally, I note that camo seems to be just a proxy, not a caching proxy. This observation, in combination with my guesses above (if correct) would justify your objection @stuartpb's suggestion on the basis of performance, thereby resolving puzzlement 2.
Remarks
Are my guesses above correct, or am I off the mark?
Also, although I think I understand your concern about the performance implications of @stuartpb's suggestion, I suspect that many GitHub users would still prefer that suggestion to be implemented, than to remain unable to embed SVGs from their GitHub repositories into their READMEs/etc without relying upon third-party solutions like rawgit.com. Might it be an acceptable stopgap until the long-term fix that you are working gets completed and implemented?
Thanks again for your efforts :)
👋 - @kivikakk and I had been chatting about this internally so I thought I'd take a quick stab at a reply since @kivikakk is likely sleeping 😄
At least, it is if we put aside the case of *.github.io. I think the latter is outside the scope of what you meant by "a GitHub domain" in your remark above.
Yes, there is no attempt to control the content of GitHub Pages sites. The use of *.github.io is explicitly for this reason.
I guess that what you meant above by "GitHub user content" is not "content provided by GitHub users"
That is more or less correct. In this discussion the primary consideration is private repository data. Anytime we are looking at a feature that can be used to access private repository data we obviously must prioritize keeping that information private above all else.
Same-origin policies would not protect Alice here because Alice's private data would also be being served by raw.githubusercontent.com.
Correct. While there are some small slightly non-obvious hurdles one would have to overcome, it is definitely possible and is the fundamental reason why most content on raw.githubuerscontent.com is served as plaintext. We only whitelist a small subset of safe file formats that render natively on this domain.
This observation, in combination with my guesses above (if correct) would justify your objection @stuartpb's suggestion on the basis of performance, thereby resolving puzzlement 2.
Beyond performance (though performance is reason enough not to pursue it), the Camo solution likely has additional issues/hurdles. Camo was never designed to access private/authenticated content. It is an image proxy that was originally designed to proxy non-HTTPS URLs such that users did not get mixed content warnings when embedding images. We proxy additional things today, but the actual proxy functionality is more or less the same. All image URLs proxied by Camo are static (and hence cacheable). We take the originally provided URL, encode the original URL into the Camo URL, request it, proxy it, and serve it. This wouldn't work with private repository content since private repository content access either requires an authenticated session (your session cookie from github.com) or it requires an authentication token (the token request parameter) like raw.githubusercontent.com. Camo wouldn't have access to either of these since camo.githubusercontent.com would have no access to a user's session and Camo URLs (as implemented today) are static and wouldn't have access to a dynamic token request parameter to authenticate access . Moreover, even if things were rearchitected to pass a token, you would run into the same issue as raw.githubusercontent.com with regard to same-origin content and malicious scripts. And, unlike the external image content served by Camo today, it would now include private repository contents. In the end, this brings us back to the same issue as serving such content from raw.githubusercontent.com.
Thanks again for your efforts :)
Agree... 🙇 to @kivikakk for digging in and working on a solution. I think the solution @kivikakk is working on is ✨ and the best long-term solution.
P.S. To all of those on this thread, thanks so much for the patience for awaiting a solution that satisfies your needs and also satisfies our security requirements. I'm sure it can feel frustrating since it seems like a feature like this should be super simple to implement. But, as you can tell from the discussion in this thread, there is a bit more nuance to this than it might first appear. There is quite a bit of consideration that has gone into our architecture around serving various types of user content, and it can be a a bit tricky to succinctly convey all of that historical context in an issue.
Hi all,
Would you like to give this a go now, and let me know if you hit any bugs? I've just noticed one with DTDs which I'm working on now.
@kivikakk are <use> elements purposely not rendered? Here's what I see when attempting to replace the image in mwclient's README with the SVG version:
For some reason, it doesn't appear to be working on the README here:
https://github.com/ioquatix/build-dependency
It just shows missing file?
I also tried here:
https://github.com/ioquatix/utopia/edit/master/README.md
There is a utopia.svg in the same place as the PNG. If I simply change the file extension, it should work, but it doesn't seem to be.
For some reason, it doesn't appear to be working on the README here:
It looks like the sanitization process is mucking up the DOCTYPE bit. The unsanitized version is as follows:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<!-- Generated by graphviz version 2.40.1 (20161225.0304)
-->
<!-- Title: G Pages: 1 -->
<svg width="357pt" height="404pt"
...
The sanitized version is as follows:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="357pt" height="404pt" viewBox="0.00 0.00 357.00 404.00">
...
If you open the sanitized version directly it doesn't render in Chrome, with an error message related to line 2 (the DOCTYPE bit).
See also my original comment announcing this:
I've just noticed one with DTDs which I'm working on now.
This will be fixed shortly. 👍
DOCTYPE fix is in. https://github.com/ioquatix/build-dependency looks better now.
Okay great it's working on both example repos above.
It didn't work with ?raw=true
@ioquatix I'm not sure what ?raw=true is meant to do here. ?sanitize=true on the raw endpoint will sanitize the SVG and render it with the appropriate Content-Type, and image references in Markdown are automatically updated to use that for SVGs.
@waldyrious this will be fixed once the cache rolls. 👍
In the past, some of my embedded images used raw=true but I'm not sure why any more.
@kivikakk Thanks for your effort sorting this out and your communication. I'm now happy this is working for my use case so I will close the issue. Awesome!!
So what's the conclusion? Can we now load SVG images on the markdown and readme file? Does it have some limitations?
@piranna Yes, SVG files in repositories can be included inline in Markdown files. They will be run through a sanitizer when viewed directly this way — tags like <script> are removed.
@piranna Yes, SVG files in repositories can be included inline in Markdown files. They will be run through a sanitizer when viewed directly this way — tags like <script> are removed.
Cool! Thanks! :-D
@kivikakk Would some of your sanitization work for this issue be useful to allow inline SVG too? I tried it out and it doesn't work.
@jaydenseric Probably not; right now it's possible to do this because SVG in the <img> tag is a completely different context from the parent page, so we don't have to worry about e.g. id collisions. We'd have to rewrite ids in the included SVG to ensure they don't collide, as well as any cross-references to those ids, which would require quite a lot more parsing of the SVG than we currently do (which is just at the XML level).
@flisky It's pretty rare that someone will embed an SVG in a gist alongside a Markdown file referring that SVG, so we may not implement this.
What's a pity. I don't think it's rare, such as UML diagrams. Anyway, thanks for the answer.
Maybe it's rare because it doesn't work :D
I think there are some rendering issues with line breaks.
Here is a screenshot of the svg rendered correctly when you view it:
And here it is rendered incorrectly in the markdown README:
@fredwu Could you contact support with some more details about this? We'd like to fix up bugs like this.
@kivikakk here are examples of broken diargams, created via draw.io
- svg is ok in browser
- broken view in readme (see png screenshot)
editable source - you can export SVG yourself.
Seems your sanitizer is a bit more aggressive than needed.
@kivikakk , do you know if this is in github enterprise yet?
@NateZimmer As of 2.12, yes!
Hi, I came across this thread trying to understand how SVGs are rendered in Markdown files. I'm entirely new to this whole HTML/Markdown/sanitization process so I apologize if this has been answered elsewhere, since I don't know what to search for.
Basically I have a SVG which uses nodes with embedded URLs, which when clicked upon will load another page automatically using xlink. All content and target URLs are hosted on github.com.
https://github.com/tcwan/ev3dev/blob/ev3dev-wiki-1/images/workflow-c-cpp.flowchart.svg
These render and work fine locally on my machine (displaying it on Github.com disables the URL xlink but renders correctly). However, once it has been uploaded and linked to the markdown file, the nodes disappear from the SVG when rendered in the browser and I lose the URL (xlink).
You can see the problem here:
https://github.com/tcwan/ev3dev/wiki/Getting-Started-Developing-on-ev3dev/3bfa69ec5096a3fde71cf2d33915bf9dd2a5f065
Using "?sanitized=true" disabled the display of the SVG entirely.
I don't understand from the discussion thread whether my use case (letting a user click on a SVG node to access a linked page) is allowed or not. If it is allowed, how should I reference the image without resorting to external non-official sites?
xlinka in SVGs are currently removed by sanitisation; I'll have a look into whether we can safely whitelist them.
It looks like this should be safe; I'll keep you updated here.
So, while I can get it to work (when I visit the sanitized SVG directly the links function as expected), they don't work when included in a parent page via <img>. So while we could correct this, it wouldn't provide the functionality you're after (and will introduce additional sanitisation requirements).
I'd prefer it to at least render the image correctly even if the xlinks don't work. i.e., to remove the xlinks and keep the rest of the node and diagram text?
Out of curiosity why don't they work when the SVG is embedded in a page, is this a limit of SVG via the <img> tag?
I just found my SVG files are rendered differently in the README page today (it used to work fine).
Here is an example, you can see the raw SVG files in /images.
@xiaohk - Apologies for the issue. We had updated some libraries today and it caused a change to how our SVG sanitizer was working. I've just deployed a fix and things should start working again soon (some SVG might remain cached for up to an hour or so). I had been using the "toki" SVG as my test while deploying, so that one was recently cached. But, all the other SVG on https://github.com/xiaohk/nippon-colors now appear to render correctly.
Looks like this is broken again due to CSP restrictions. Sample error from console:
README.md:1 Refused to load the image 'https://raw.githubusercontent.com/leannotes/leannotes/master/tags/useful-tool.svg?sanitize=true' because it violates the following Content Security Policy directive: "img-src 'self' data: assets-cdn.github.com media.githubusercontent.com camo.githubusercontent.com identicons.github.com collector.githubapp.com avatars0.githubusercontent.com avatars1.githubusercontent.com avatars2.githubusercontent.com avatars3.githubusercontent.com github-cloud.s3.amazonaws.com".
EDIT: Actually, this change breaks all image embedding, not just SVG. Sending an email to support about it now.
FOLLOWUP: This appears to be fixed now.
apologies..we had just merged a PR that bumped a library related to CSP and it caused some whitelisted hosts to get removed. I reverted that change and will see what the underlying issue was.
This feature is still not working inside the wiki repo. See this test wiki page. The first block there is a relative link to img/sphere_dda.svg, which is not working.
The second block is a workaround with hardcoded absolute link (with sanitize) - https://raw.githubusercontent.com/wiki/adda-team/adda/img/sphere_dda.svg?sanitize=true
Third block shows that everything is working fine (with relative links) for png images. Moreover, svg images are also working in a branch of the source repo - see, e.g., here.
It seems that the problem (inside the wiki repo) boils down to not adding ?sanitize=true when transforming the relative path to svg into the absolute path at raw.githubusercontent.com
I was not having problem with adding SVG image using relative path lately, just like this:
Then, after pushing my changes to the repo I have right-clicked on the image (which was visible of course) and was able to see that the ?sanitize=true was added at the end of the image path.
It seems that the issue is resolved and can be closed.
@gucu112 , the limitations described in my comment above - #556 (comment) - are still present. So the issue is only half-resolved.
@myurkin Sorry, I didn't know it is still issue for wiki pages (as I was tested for README.md file).
@kivikakk Well it appears that any style tags found inside of the defs gets stripped by the sanitizer as well. For example, a font-face from google open source fonts @import'ed with CSS inside the SVG get stripped completely from the SVG file. This breaks the rendering of the image text.
Broken here: https://github.com/mkormendy/MechanicalSoup
Should look like:
@myurkin this has now (finally) been fixed!
@mkormendy we're mulling the security implications of allowing @import (we currently sanitise CSS in the svg, and obviously the contents of an @import cannot be sanitised). I'll let you know where we end up on this.
@mkormendy we did some digging to determine the implications of allowing this and ended up discovering it wouldn't make a difference if we did -- it turns out that all external resources will be ignored by browsers when an SVG is being displayed via an <img> tag. MDN documents this, and while I can't find any official documentation re: e.g. Chrome, my own local testing confirms that the browser makes no attempt to load the external resources. The W3 wiki notes:
The SVG document is not allowed to fetch any resources. This also applies to scripts, stylesheets or images.
So I think converting the SVG to a png as you have is as good as it gets.
@kivikakk That's absolutely correct (based on my own research into this). Referencing an SVG using an <img> tag rasterizes the image and prevents it from further loading anything. It's basically inert.
Here's the most relevant literature I know about what SVG features are available when using the <img> tag: https://www.smashingmagazine.com/2014/11/styling-and-animating-svgs-with-css/#embedding-svgs
This is the key clause:
Styles and animations applied to an SVG using an external CSS resource will not be preserved once the SVG is embedded.
Basically, the SVG can't make any external references.
If the font is small then data: URI is also a solution.
@mkormendy we did some digging to determine the implications of allowing this and ended up discovering it wouldn't make a difference if we did -- it turns out that all external resources will be ignored by browsers when an SVG is being displayed via an
<img>tag. MDN documents this, and while I can't find any official documentation re: e.g. Chrome, my own local testing confirms that the browser makes no attempt to load the external resources. The W3 wiki notes:The SVG document is not allowed to fetch any resources. This also applies to scripts, stylesheets or images.
So I think converting the SVG to a png as you have is as good as it gets.
It's documented here: https://www.w3.org/TR/SVG2/conform.html#processing-modes
SVG when loaded as an <img> or CSS background-image (or any other way that's an image rather than a document) cannot execute script and must be self contained i.e. can't load any other external resources. This is basically so that your thought process for "should I support images" does not need to depend on also asking yourself whether the image is a raster image or an SVG image.
FWIW I'm one of the authors of SVG support in Firefox.
@longsonr thanks for following up with this. I guess the implications of this weren't fully planned out even though the code has partial allowance for this and has operational success in some instances. I love the work that the W3C has done to document web convention, however they are inherently monolithic in their approach, and as such, are prone to common pitfalls like incomplete strategies and speed of correction (or lack of awareness to correct in the first place).
That being said, I have no basis at the time for requiring this any further, but in the future someone might. Researching the correct security handling for such a scenario could be extensive, but I do believe (beyond the W3C) that there are others who have done part of the leg work for figuring out this branch of the requirement and it's just a matter of putting the pieces together. This is my final word on this.
Hi all.
It's still an issue if image is too big and you want to make it a link pointing to a full screen display of SVG source.
[](./assets/img.svg)It works okay while viewed through MD, but on click it'll show "Sorry, this file is invalid so it cannot be displayed":
I expected that this raw + sanitize workaround will work, but no:
[](./assets/img.svg?raw=true&sanitize=true)GitHub drops sanitize=true while resolving raw url, as @myurkin mentioned in #556 (comment):
It seems that the problem (inside the wiki repo) boils down to not adding
?sanitize=truewhen transforming the relative path to svg into the absolute path atraw.githubusercontent.com
@anton-rudeshko You should try
Thank you for your suggestion, I'll try it. And yet I'm not sure if GH Enterprise have anything like rawgithub subdomain.
@Mizux Note that it's a third-party website. Even worse it has reached End-of-Live. See https://rawgit.com/ (RawGit and raw-GitHub are the same website; both domains point to the same IP address.)
Hey there !
I want to know why does my repo does show the SVG in ReadME file but not on my public profile.
Basically, I had made this SVG that should be showcased on my public profile, but due to some error its only showing in repo and not on my public profile