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
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/wikitech-l