I've enabled SVG uploads and rendering.
SVG images are automatically rendered to PNG for thumbnails and inline display, currently using rsvg (of librsvg) as a converter backend. (If anybody sets up new Apaches in the cluster, make sure the librsvg2 package is installed.)
Note that some old SVGs might have bogus size information if the image table which causes rendering to fail; I'll try to get that worked out, but as a workaround you can re-upload the file.
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
I've enabled SVG uploads and rendering.
SVG images are automatically rendered to PNG for thumbnails and inline display, currently using rsvg (of librsvg) as a converter backend. (If anybody sets up new Apaches in the cluster, make sure the librsvg2 package is installed.)
Note that some old SVGs might have bogus size information if the image table which causes rendering to fail; I'll try to get that worked out, but as a workaround you can re-upload the file.
-- brion vibber (brion @ pobox.com) _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
It might be useful to mention here that Firefox 1.5beta1 now has SVG support compiled in and enabled by default. The implementation is still slightly buggy, but works well enough for content developers to use for testing, to try to shake out as many bugs as possible before 1.5 proper is released.
-- Neil
On Sat, Sep 10, 2005 at 10:48:48AM +0100, Neil Harris wrote:
Brion Vibber wrote:
I've enabled SVG uploads and rendering.
It might be useful to mention here that Firefox 1.5beta1 now has SVG support compiled in and enabled by default. The implementation is still slightly buggy, but works well enough for content developers to use for testing, to try to shake out as many bugs as possible before 1.5 proper is released.
Since SVG allows the embedding of javascript, we should not deliver SVG's that were uploaded to our users, unless someone provides a reliable javascript remover.
Regards,
JeLuF
Jens Frank wrote:
On Sat, Sep 10, 2005 at 10:48:48AM +0100, Neil Harris wrote:
Brion Vibber wrote:
I've enabled SVG uploads and rendering.
It might be useful to mention here that Firefox 1.5beta1 now has SVG support compiled in and enabled by default. The implementation is still slightly buggy, but works well enough for content developers to use for testing, to try to shake out as many bugs as possible before 1.5 proper is released.
Since SVG allows the embedding of javascript, we should not deliver SVG's that were uploaded to our users, unless someone provides a reliable javascript remover.
A checker for JavaScript was included in 1.5 branch a couple months back. Of course another look over the code wouldn't hurt!
(We have for some time taken the precaution of serving uploads from a separate subdomain, which should in most cases prevent attacks even if they make it past upload filters; but it may not be complete protection, particular for the sites on *.wikimedia.org domains where there might be a session fixation attack.)
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
Jens Frank wrote:
Since SVG allows the embedding of javascript, we should not deliver SVG's that were uploaded to our users, unless someone provides a reliable javascript remover.
A checker for JavaScript was included in 1.5 branch a couple months back. Of course another look over the code wouldn't hurt!
(We have for some time taken the precaution of serving uploads from a separate subdomain, which should in most cases prevent attacks even if they make it past upload filters; but it may not be complete protection, particular for the sites on *.wikimedia.org domains where there might be a session fixation attack.)
Just for completeness sake, we should block _all_ scripting languages if we are not doing so already, as Microsoft browsers, I believe, can also execute other scripting languages such as Visual Basic, and there are moves to add support for other scripting languages besides JavaScript in Mozilla / Firefox products soon.
-- Neil
Brion Vibber wrote:
Jens Frank wrote:
Since SVG allows the embedding of javascript, we should not deliver SVG's that were uploaded to our users, unless someone provides a reliable javascript remover.
A checker for JavaScript was included in 1.5 branch a couple months back. Of course another look over the code wouldn't hurt!
(We have for some time taken the precaution of serving uploads from a separate subdomain, which should in most cases prevent attacks even if they make it past upload filters; but it may not be complete protection, particular for the sites on *.wikimedia.org domains where there might be a session fixation attack.)
Just for completeness sake, we should block _all_ scripting languages if we are not doing so already, as Microsoft browsers, I believe, can also execute other scripting languages such as Visual Basic, and there are moves to add support for other scripting languages besides JavaScript in Mozilla / Firefox products soon.
-- Neil
On Sat, Sep 10, 2005 at 04:00:26AM -0700, Brion Vibber wrote:
Jens Frank wrote:
On Sat, Sep 10, 2005 at 10:48:48AM +0100, Neil Harris wrote:
Brion Vibber wrote:
I've enabled SVG uploads and rendering.
It might be useful to mention here that Firefox 1.5beta1 now has SVG support compiled in and enabled by default. The implementation is still slightly buggy, but works well enough for content developers to use for testing, to try to shake out as many bugs as possible before 1.5 proper is released.
Since SVG allows the embedding of javascript, we should not deliver SVG's that were uploaded to our users, unless someone provides a reliable javascript remover.
A checker for JavaScript was included in 1.5 branch a couple months back. Of course another look over the code wouldn't hurt!
Wow! That's nice :-)
JeLuF
I've turned SVG upload and rendering back off for now.
rsvg/librsvg doesn't seem to provide any ability to shut off inclusions of image files from the filesystem, nor does the current filter prevent such uploads. This could be abused at a minimum to read an image with a known filename from the restricted internal wiki, given knowledge of the filesystem layout on the server (which is easy to get given our open documentation).
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
I've turned SVG upload and rendering back off for now.
rsvg/librsvg doesn't seem to provide any ability to shut off inclusions of image files from the filesystem, nor does the current filter prevent such uploads. This could be abused at a minimum to read an image with a known filename from the restricted internal wiki, given knowledge of the filesystem layout on the server (which is easy to get given our open documentation).
I've hacked in an embargo on external file references in librsvg, so it's back on. Whee!
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
I've hacked in an embargo on external file references in librsvg, so it's back on. Whee!
Oh and here's my hack patch: http://sourceforge.net/mailarchive/forum.php?thread_id=8165206&forum_id=...
-- brion vibber (brion @ pobox.com)
wikitech-l@lists.wikimedia.org