Last modified: 2012-01-02 03:17:00 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T33719, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 31719 - SVG metadata reader has troubles when the xmlns is set to an entity reference
SVG metadata reader has troubles when the xmlns is set to an entity reference
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
1.18.x
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-reviewed
Depends on:
Blocks: 31720
  Show dependency treegraph
 
Reported: 2011-10-15 02:18 UTC by Saibo
Modified: 2012-01-02 03:17 UTC (History)
6 users (show)

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


Attachments
Whitelist the Adobe svg namespace entity as being equal to the actual SVG namespace. (916 bytes, patch)
2011-12-03 12:33 UTC, Derk-Jan Hartman
Details

Description Saibo 2011-10-15 02:18:13 UTC
http://commons.wikimedia.org/wiki/File:Toll_Texas_1.svg   I saw  four thumbs in the history - the 1 2 7 and 9th version. If I revert to the 8th version they all vanish.
Comment 1 Mark A. Hershberger 2011-10-18 12:00:39 UTC
Wonder if this could be related to the fix we made for deleting old thumbnails.
Comment 2 Bawolff (Brian Wolff) 2011-10-18 13:18:55 UTC
It looks to be related using an entity reference in an xmlns attribute. Our svg reader that determines the size of an svg doesn't expand the entity, so it doesn't recognize the starting svg tag as being in the right namespace (from debug log: SvgHandler::getMetadata: Expected <svg> tag, got svg in NS &ns_svg; )

This is possibly an upstream issue with whichever xml library we use to read svgs.

However, didn't we use to assume the image was 200x200 if we couldn't find a width/height, or something like that(?)
Comment 3 Brion Vibber 2011-10-19 19:04:12 UTC
Rendering problems with same example file in bug 31720 are probably related to this.
Comment 4 Derk-Jan Hartman 2011-12-03 12:32:10 UTC
Actually, to fix this, you set

XMLReader::setParserProperty(XMLReader::SUBST_ENTITIES, true)

Problem is however that this opens you up to entity expansion xmlbombs. I'm not sure if XmlReader sets safe limits to prevent this, an where or how those limits are set.

Alternatively, i think we could just whitelist this case. Patch attached.
Comment 5 Derk-Jan Hartman 2011-12-03 12:33:14 UTC
Created attachment 9602 [details]
Whitelist the Adobe svg namespace entity as being equal to the actual SVG namespace.
Comment 6 Bawolff (Brian Wolff) 2011-12-27 02:59:12 UTC
I applied that in r107359. I'm not sure if its the "best" fix (hence i'm leaving the bug open), but its certainly an improvement over current situation.
Comment 7 Tim Starling 2012-01-02 03:17:00 UTC
(In reply to comment #4)
> Actually, to fix this, you set
> 
> XMLReader::setParserProperty(XMLReader::SUBST_ENTITIES, true)
> 
> Problem is however that this opens you up to entity expansion xmlbombs. I'm not
> sure if XmlReader sets safe limits to prevent this, an where or how those
> limits are set.

We can use XMLReader::SUBST_ENTITIES, libxml2 does limit it. Recursive entity declarations generate an error "Detected an entity reference loop", and there are some heuristics in xmlParserEntityCheck() that look like they are intended to protect against some more obscure cases.

Committed in r107793.

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


Navigation
Links