Update sanitization filter to allow data: URIs in img tags #227
Conversation
Allowing data: URIs as values for the src attribute adds great convenience without introducing any security issues.
|
As per a discussion at github/markup#270, this should be safe enough. |
|
nice 👍 |
|
@mastahyeti I see you were referenced in the other thread. Any thoughts on
|
|
There were a number of concerns brought up in github/markup#270. I think we'd need to suss those out before making this change for github.com. Specifically:
|
|
If supporting |
|
Any news on this and how soon it can be integrated? How do you enforce |
|
does this mean that I can't use base64 encoded svg images in README.md files? (yet) |
|
I urge you, good and courageous people, to click "Merge" with all haste. |
|
Would love that feature too, so that we don't have to host images |
|
We are looking for support of this feature too - using the following markdown format is still not displaying the base64 image as it should: Please get this live ASAP as it will assist development no end to get a visual when a user reports an issue with countless apps that rely on GIT. Thanks all. |
|
@jch Could you kindly merge this PR or explain your concern? Thanks :) |
|
+1 |
| @@ -81,7 +81,7 @@ class SanitizationFilter < Filter | |||
| 'ins' => {'cite' => ['http', 'https', :relative]}, | |||
| 'q' => {'cite' => ['http', 'https', :relative]}, | |||
| 'img' => { | |||
| 'src' => ['http', 'https', :relative], | |||
| 'src' => ['http', 'https', 'data', :relative], | |||
|
Hi all, any idea of an ETA when this will actually be live? Thanks in advance. |
|
Any further thoughts/discussion here? |
|
👍 |
1 similar comment
|
👍 |
|
I think it's time to reopen discussion on why this is not being accepted. |
|
Me too. I was playing around with SVGs in Github Flavored Markdown today and ran into this limitation (again; I'd forgotten I'd run into several years ago). I suppose there could be an additional security angle, but...I wish this worked. Here's my use case. I am working on a design system and there's a component for our set of icons. With something visual, it's often essential to have...a visual. But we're not committing the SVG files of our icons as individual assets. With our setup, this would be both unnecessary and noisy; individual files are created during builds and published, but not tracked as source code in the repo. Wouldn't it be neat, I thought, if you could just see the icons in the README? No need for me to deploy a site. And if I could inline them, I wouldn't have to add the noise of committing assets just to display them, the noise of the README itself would be made up for because we wouldn't have to worry about files hosted elsewhere going poof & breaking our docs (especially previous versions), etc. This approach also happens to work very nicely with the tools I'm using to build and plans I've got for the future. So, I tried URL encoding an SVG and using a data URI. The idea is that I could just write the icons directly to my README and, unsurprisingly, it does not work. For a little more info and examples of how this works outside of GitHub, see https://css-tricks.com/probably-dont-base64-svg. PS: There are all kinds of things that are awful, unreadable messes in the e-mail notifications I get from GitHub, so I really don't think that, at least, should be considered a legitimate blocker. |
|
Here's a demo with a script inside the SVG. https://codepen.io/morewry/pen/rdQevJ?editors=1001 I checked this in IE 10, IE 11, Yandex 14.12, Opera 52, Opera 51, Safari 8, Safari 9.1, Safari 10.1, Safari 11, Firefox 58, Firefox 59, Chrome 64, Chrome 65, Edge 15, and Edge 16. No unexpected console output appears. |
|
Sure would be nice if it wasn't impossible to show all the icons of my icons repo in the README. What's worse is that if this weren't a paid for private repo, it'd be a lot easier. |
|
I hope to give this PR a push with a ping. (The branch is now in a conflicting state but it's easy to resolve. Happy to help, if that helps. May it be the only thing that blocks this from merging.) |
|
My impression was that this was blocked because of other reasons - not just because of the stale PR, but I've merged Repository owners, please let me know if you'd like me to squash and rebase the commit - happy to do that too. |
|
Let the merge of this PR be a True Christmas Miracle! |
|
I'm not sure who has write access and who doesn't (I don't), but as has been discussed in several other places: this gem is no longer the basis of HTML processing for github.com, and so changes made here will not be seen on GitHub itself. |
|
@kivikakk then why github/markup#270 is closed as off-topic? What/where should be changed to allow embedding images in markdown media? |
|
My last comment on the issue is exactly what explains why it's closed as off-topic, and tells you exactly where to reach out to. Thanks. |
|
It's mid of 2019 and the feature is not yet there.. quite disappointed, since embedding tiny Base64 images into markdown documents is a very convenient feature. |
|
Any updates regarding when this will get merged. Its been a long time and everyone seems to be waiting . . . |
I do have to say closing it as off topic and suggesting a reach-out to github.com/contact just completely removes any ability for people to track down whether this feature will eventually be implemented, and an issue tracker is also a great way to have some transparency. its been 5 years since this support has been requested, so I don't feel writing to ask what is going on? |
Allowing data: URIs as values for the src attribute
adds great convenience without introducing any
security issues.