Last modified: 2014-10-15 08:41:05 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 3537 - SVGs fail to render silently if they contain an <image /> element
SVGs fail to render silently if they contain an <image /> element
Status: NEW
Product: Wikimedia
Classification: Unclassified
SVG rendering (Other open bugs)
unspecified
All All
: Normal normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 7645
Blocks: 41371
  Show dependency treegraph
 
Reported: 2005-09-23 13:25 UTC by ejsanders
Modified: 2014-10-15 08:41 UTC (History)
7 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description ejsanders 2005-09-23 13:25:37 UTC
Obviously the <image /> element is disabled, but it should be stripped, or at
least alert the user to the problem, as many users don't know why their SVGs
aren't rendering.
Comment 1 Brion Vibber 2005-09-23 23:34:04 UTC
<image> is supported, but only for embedded data: urls.
Comment 2 ejsanders 2005-09-24 12:30:27 UTC
I don't understand:
http://en.wikipedia.org/wiki/Image:Map_of_USA_with_state_names.svg failed to
render the first version, the new version works and the only change was the that
I removed the <image /> element.
Comment 3 Brion Vibber 2005-09-25 06:08:31 UTC
Let's look at that <image>:
  <image
     xlink:href="USA_highway_map.png"
     sodipodi:absref="/home/eric/wiki/USA/USA_highway_map.png"
     width="893.71935927"
     height="568.20873295"
     id="image960"
     x="27.34392929"
     y="150.91799927"
     sodipodi:insensitive="1" />

Notice how the url it uses to reference the image resource is a 
relative path, *not* an embedded data: url. It refers to an external 
file, which:
1) Is not allowed by our security policy on the renderer.
2) Wouldn't work anyway since the referenced file wouldn't be there.
Comment 4 ejsanders 2005-09-26 08:45:22 UTC
The bug isn't that the <image> doesn't work, but that it fails silently. It
should either strip disallowed image elements then render, or alert the user to
the violation of the security policy, so they can fix the image.
Comment 5 Brion Vibber 2005-09-26 19:28:41 UTC
Yes, that's why the bug hasn't been closed. :)

You asked why a particular image failed.
Comment 6 ejsanders 2005-09-26 19:54:54 UTC
(In reply to comment #5)
> Yes, that's why the bug hasn't been closed. :)
> 
> You asked why a particular image failed.

Ah, I was just giving it as an example, I though you were disagreeing with me
with your first comment.
Comment 7 Daniel Kinzler 2005-09-26 19:58:08 UTC
I agree that there should be an error message on the description page. Or, even
better, this should be detected on upload, and the image rejected.
Comment 8 Jeff Schiller 2009-02-24 03:37:13 UTC
Just to confirm:  

1) data: URLs _ARE_ allowed and supported in the svg image uploads + rasterization to PNGs that happen on wikimedia?

2) do you scrub data: URLs to ensure that someone hasn't injected another SVG image (with potentially malicious script)?

If the answer is yes to both the above questions, then a potential solution is to update Inkscape so that upon importing a raster image, the user is presented with 3 options:  a) embed raster as base64 data:, b) reference local file, c) reference a foreign URL - with sufficient explanations for these three options that a newbie can understand (i.e. "choose option a if you are uploading this file to wikipedia or openclipart")

If I get some feedback here I can open a bug and help push it along for Inkscape (if it hasn't been opened already - if there is an open bug, please link to it here).

Regards,
Jeff Schiller
Comment 9 Jeff Schiller 2009-04-25 20:56:33 UTC
FYI, I have finally opened <a href="https://bugs.launchpad.net/inkscape/+bug/366993">Bug 366993</a> against Inkscape for this issue.
Comment 10 Brion Vibber 2009-08-03 16:53:43 UTC
Assigning SVG bugs to Ariel -- need a cleanup pass to see what's fixed up by a librsvg upgrade, what can be resolved with fixes to our font configuration, what can be fixed on our end, and what still needs to be pushed upstream.
Comment 11 Ariel T. Glenn 2009-08-06 21:01:55 UTC
Say, I can't actually look at the launchpad bug to see what's up, it's marked private... Jeff, can you do anything about that?
Comment 12 Brion Vibber 2009-08-06 21:06:00 UTC
Data URIs _should_ currently work fine; at the moment we implement the restriction against external images by patching librsvg so it literally can't load external resources.

To generalize it via an upload-time check we would indeed want to be able to decode sub-SVG images to check for additional external resources in them; that's a detail I hadn't thought of earlier. :) Still shouldn't be absurdly hard to implement. I'm adding bug 7645 "Validate SVG content" as a dep for this...

And yes, would be very happy if Inkscape would start defaulting to embedding rasters when you add them!
Comment 13 Smallman 2010-05-17 13:40:12 UTC
Although the <image> element is disabled for thumbnailing, if the user clicks on the thumbnail to enlarge the image, or is given a link to an image, the <image> element is still present.

As SVG's are rendered in firefox, an image with a "xlink:href" to a malicious image file would still go through. Or at least the user's IP would be revealed.

As an example, see http://upload.wikimedia.org/wikipedia/commons/archive/9/9b/20100517130343!Kyokuryu-kai.svg in which you can see the google logo in the background. This is done by adding 
  <image
     xlink:href="http://www.google.com/intl/en_ALL/images/srpr/logo1w.png"
     x="-55.373806"
     y="-55.316906"
     width="1100"
     height="1100"
     id="image2888" />

All SVGs with "xlink:href" should be marked with some type of warning, or the "xlink:href" stripped or commented out.
Comment 14 Derk-Jan Hartman 2010-11-04 01:10:23 UTC
There is now an SVGParser in SVGMetadataExtractor.

I guess we could switch the SVG upload filter to this new mediahandler filter and have it look for xlink:href uri's. We could then warn when a file should not be uploaded. It's not hard to do I guess..
Comment 15 Ariel T. Glenn 2011-09-18 09:13:26 UTC
giving SVG bugs back to the pool.
Comment 16 Brion Vibber 2013-09-19 15:15:12 UTC
Switching to Wikimedia/SVG Rendering component.
Comment 17 PRO 2014-10-15 08:41:05 UTC
Currently the image-tag get stripped, which made the SVG useless (upload). So I recommend to made a big warning (as reported on Commons: VP).

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links