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_…
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
