Hi,
After participating in several discussions about SVG on the wikis, it appears that SVG uploading is currently impossible by design. As I understand it, the uploading of SVG is disabled because of concerns about SVG containing malware.
I have written an SVG sanitizer that detects (and removes, although this may not be useful) the presence of script tags in SVG. It still requires some fine-tuning to match the requirements of the wikis, so I am inquiring to find out what those requirements actually are.
Some background: SVG is a form of XML. The SVG specification describes a number of features, including vector art, animation, inclusion of external resources, and scripting. It is also possible (and not difficult) to incorporate non-SVG XML inside an SVG file; individual SVG viewers may ignore or interpret this XML. Some examples include metadata tags (in RDF) and program-specific SVG extensions.
In Wikipedia, there are a few diferent things we might wish to do with SVG:
* Simply store it for upload/download to provide diagrams (such as http://commons.wikimedia.org/wiki/Image:Thermal_reactor_diagram.png ) with accompanying source, so that they can be modified (the text translated, for example).
* Render it on the server to generate PNGs at any desired resolution (as is done, badly, with http://en.wikipedia.org/wiki/Image:Bi-flag.svg )
* Serve it up as an image so that it can be rendered in a browser (such as the non-free Adobe SVG plugin, konqueror, or the SVG-enabled version of Mozilla). (This is the only option that would make any use of the (poorly-supported) animation and scripting capabilities of SVG).
I am suggesting only the first: simply serve it up for download. There are software issues with the second (no entirely satisfactory rendering software exists; librsvg, batik, and inkscape are the leading free contenders). The third would require more extensive software modifications and would only really be useful if the second worked.
The concern with this application is that the files may contain hostile scripts which will be run by users who download the files and attempt to edit them (akin to Word macro viruses). (I know of no current SVG editor that implements any form of scripting).
The questions that need to be answered before SVG upload could be re-enabled are:
* What non-SVG content may an SVG file contain? Metadata is common (for example in the openclipart library of PD SVG files), as are program-specific extensions. If undesired non-SVG content is found, should it be removed, or should the file be rejected? (Users of CorelDraw (for example) may find it difficult to persuade CorelDraw to produce a pure SVG file).
* Is it sufficient to remove all scripting elements from an SVG file? (are external resources a concern? animations?) Should files containing scripting elements have them removed, or should the files be rejected?
It would also be necessary for someone with experience with the Mediawiki software to figure out how to integrate an SVG sanitizer with the software.
Discussions of SVG support and its desirability:
The original post to this mailing list in which Brion VIBBER announced that he had disabled SVG: http://mail.wikipedia.org/pipermail/wikitech-l/2004-September/025467.html
I asked about SVG support; a bad workaround was suggested; vague allusions to security problems were made; a workaround was suggested: http://commons.wikimedia.org/wiki/Commons:Village_pump_archive-11#SVG
[[en:User:KrisK]] asked about SVG support; I noted it was disabled; Brion VIBBER gave a partial answer about why it was disabled. http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28policy%29#raster_vs_v...
A recent version of my SVG sanitizer script: http://en.wikipedia.org/wiki/User:Aarchiba/SVG_sanitizer
In summary: What are the criteria for re-enabling SVG support? There is increasing demand for it, and it can be effectively sanitized.
Thanks, Andrew