Change Details

As a result of 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. **How to reproduce** 1. Create a new drawing at [[ https://www.draw.io/ | draw.io ]] 2. Add a box with text inside 3. Export as SVG 4. Upload to MediaWiki 1.26 or newer **Actual Result** ``` This SVG file contains an illegal namespace "http://www.w3.org/1999/xhtml" ``` **Expected Result** Successful File Upload (as there's no iframe in the SVG) **Impact** 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 [[ https://github.com/mgeb/mediawiki-drawio-editor | mine ]]. See this issue on GitHub: https://github.com/mgeb/mediawiki-drawio-editor/issues/1 **Details** 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. **Suggested fix** 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.

This RFC explores having MediaWiki allow SVG files to have XHTML namespaces on upload. This was disabled as a result of {T62771}. However, legitimate SVG files are also blocked, e.g. the ones produced by draw.io. 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. 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? Full RFC: https://www.mediawiki.org/wiki/Requests_for_comment/SVG_Upload_should_(optionally)_allow_the_xhtml_namespace

As a result of 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 issueThis RFC explores having MediaWiki allow SVG files to have XHTML namespaces on upload. This was disabled as a result of {T62771}. However, the former prevents legitimate SVG files from being uploadedare also blocked, e.g. the ones produced by draw.io. **How to reproduce** 1.Native SVG lacks proper word wrapping support, Create a new drawing at [[ https://www.draw.io/ | draw.io ]] 2.at least in current implementations, Add a box with text inside 3and this can be circumvented by using xhtml and CSS if the displaying application supports that. Export as SVG 4.In case it does not, Upload to MediaWiki 1.26 or newerthe less optimal SVG version will be used. **Actual Result** ``` This SVG file contains an illegal namespace "http://www.w3.org/1999/xhtml" ``` **Expected Result** Successful File Upload (as there's no iframe in the SVG)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? **Impact** 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 [[ https://github.com/mgeb/mediawiki-drawio-editor | mine ]]. See this issue on GitHub: https://github.com/mgeb/mediawiki-drawio-editor/issues/1 **Details** 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. **Suggested fix** 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.Full RFC: https://www.mediawiki.org/wiki/Requests_for_comment/SVG_Upload_should_(optionally)_allow_the_xhtml_namespace