Requests for comment/SVG Upload should (optionally) allow the xhtml namespace

From mediawiki.org
Jump to navigation Jump to search
Request for comment (RFC)
SVG Upload should (optionally) allow the xhtml namespace
Component General
Creation date 2016-10-26
Author(s) Markus Gebert
Document status in draft
See Phabricator.

Background[edit]

As a result of Phab:T62771 SVG uploads have been restricted to certain namespaces. Additionally, a check has been added to disallow xhtml iframes in SVG files. While the latter is necessary to fix the XSS issue, the former prevents legitimate SVG files from being uploaded, e.g. the ones produced by draw.io.

See also Inline SVG use.

Problem[edit]

To witness this problem:

  1. Create a new drawing at https://www.draw.io
  2. Add a box with text inside
  3. Export as SVG
  4. Upload to MediaWiki 1.26 or newer

This will result in:

This SVG file contains an illegal namespace "http://www.w3.org/1999/xhtml

This is a problem for users trying to upload draw.io SVG exports directly and also for extensions that integrate the embedded version of the draw.io editor like Extension:DrawioEditor (See this issue on GitHub: https://github.com/mgeb/mediawiki-drawio-editor/issues/1

The reason for draw.io to use the xhtml namespace is that native SVG lacks proper word wrapping support, at least in current implementations, and this can be circumvented by using xhtml and CSS if the displaying application supports that. In case it does not, the less optimal SVG version will be used.

Proposal[edit]

What draw.io does seems reasonable to me. So I'd suggest to reconsider the conclusion in T62771 that any xhtml in SVG is dangerous and not used in the wild. Then again I understand that allowing the xhtml namespace might raise security concerns apart from iframes. So in the end this should be an administrator decision, i.e. a configuration option to turn the xhtml namespace on or off, or one to extend the list of allowed namespaces.

Discussion[edit]

This is a reverse chronological summary of the discussion

2016-10-24[edit]

This was discussed in an ArchCom-RFC meeting (Phab:E325).