Re: [webkit-dev] SVG Stabilization
On Feb 25, 2007, at 16:26 , Oliver Hunt wrote:
[...]
Dealing with loops is relatively trivial (we already have do this
for the toString and join methods on JS/DOM arrays) so i don't
think those are significant problems (though obviously we would
need a few test cases to ensure that we actually stop them --
saying we have, when we haven't would cause badness). Briefly the
paint method would require (very-pseudo-code, and i'm not sure
whether this logic should occur in the paint code, or when
constructing the render tree)
SVGUseElemenT::paint(...)
{
static HashSet paintedElems;
if (paintedElems.contains(this))
return;
paintedElems.add(this)
...
magical painting code
...
paintedElems.remove(this)
}
If space (one bit) is available and if painting is guaranteed to be
single-threaded,
a simple boolean flag in the element should suffice for this purpose
(is_being_painted).
Given that a static HashSet doesn't solve the threading issue anyway,
the only issue is whether there is a bit available in the Elements and
if the objects can be (temporarily) mutated during painting.
The actual code may have to deal with abnormal termination of the
painting sequence
though (all flags must be cleared).
Eric
Now this might cause us to incorrectly filter out some nodes (i
vaguely recall svg provides a few flow control structures, which
might in effect cause they same use element to render differently
in different cases, i haven't really looked into it). That said, I
doubt this will occur in a significant number of cases, and in the
mean time at least this seems to be an acceptable mechanism for
preventing looping badness.
--
Eric Gouriou
[EMAIL PROTECTED]
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SVG Stabilization
This covers the "hairy" parts. Complex deep references, circular
references,
self-references. All test work excellent w/o crashs or leaks.
How about cases like this:
- referencing which contains another referencing
something else (valid double use chain).
- valid chains of larger size, like 2 or 3
- inside one referencing another which contains a
reference back to the original (loop with two
elements referencing each other's parents)
- inside a marker
- referencing a path with markers
- referencing a path with markers which themselves contain
references (valid ones)
- referencing a path with markers which themselves contain
references to a parent of the original (invalid loop
via markers)
I'm sure there must be other complex cross-referencing cases along
these lines.
Dealing with loops is relatively trivial (we already have do this for
the toString and join methods on JS/DOM arrays) so i don't think
those are significant problems (though obviously we would need a few
test cases to ensure that we actually stop them -- saying we have,
when we haven't would cause badness). Briefly the paint method would
require (very-pseudo-code, and i'm not sure whether this logic should
occur in the paint code, or when constructing the render tree)
SVGUseElemenT::paint(...)
{
static HashSet paintedElems;
if (paintedElems.contains(this))
return;
paintedElems.add(this)
...
magical painting code
...
paintedElems.remove(this)
}
Now this might cause us to incorrectly filter out some nodes (i
vaguely recall svg provides a few flow control structures, which
might in effect cause they same use element to render differently in
different cases, i haven't really looked into it). That said, I
doubt this will occur in a significant number of cases, and in the
mean time at least this seems to be an acceptable mechanism for
preventing looping badness.
As for the non-looping issues, i haven't really though about it in
enough detail to be able to comment
--Oliver
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SVG Stabilization
On Feb 25, 2007, at 3:32 AM, Nikolas Zimmermann wrote: Hey Maciej, Seems like there is rough consensus around this plan. So I filed bugs to disable the experimental features for now: http://bugs.webkit.org/show_bug.cgi?id=12883 And to do some kind of additional testing/review of the various SVG microsyntax parsers (it turns out there are a lot): http://bugs.webkit.org/show_bug.cgi?id=12884 Perfect. I think this covers most cases. Some people have suggested that should also be left on. I think to make this possible would require significant additional testing, including test cases of unusual situations like circular references, nested references, etc. If anyone wants to do that testing, feel free, and ideally please document it with test cases. Note: rewriting in a completely different way is unlikely to make it more suitable for prime time, since the biggest problem with it is that it is new, relatively untested code. Agreed, it's definately new code, though the scenarios you are mentioning are covered by tests (LayoutTests/svg/custom). In detail: SVGElementInstance tests / (SVG) DOM scripting: use-elementInstance-event-target.svg use-elementInstance-methods.svg use-instanceRoot-modifications.svg use-modify-container-in-target.svg use-modify-target-container.svg use-modify-target-symbol.svg use-property-changes-through-dom.svg use-property-changes-through-svg-dom.svg All of these tests operate on the new SVGElementInstance interfaces. (instanceRoot method of SVGUseElement, returns the root SVGElementInstance). The built SVGElementInstance tree is tested automatically within use-elementInstance-methods.svg (checks instance tree consistency) event handling on : use-event-handler-on-referenced-element.svg use-event-handler-on-use-element.svg Tests the various ways to set up event listeners on elements: either on the element itself, or on the referenced element. events have to be propagated to the SVGElementInstance (!) object, not the original referenced element, nor our internal clone. on tests: use-forward-refs.svg use-recursion-1.svg ( on which references the itself again.) use-recursion-2.svg ( direct self-referencing> use-recursion-3.svg ( on , containing a which references itself) use-recursion-4.svg (same like -3.svg, but one level deeper referencing) This covers the "hairy" parts. Complex deep references, circular references, self-references. All test work excellent w/o crashs or leaks. How about cases like this: - referencing which contains another referencing something else (valid double use chain). - valid chains of larger size, like 2 or 3 - inside one referencing another which contains a reference back to the original (loop with two elements referencing each other's parents) - inside a marker - referencing a path with markers - referencing a path with markers which themselves contain references (valid ones) - referencing a path with markers which themselves contain references to a parent of the original (invalid loop via markers) I'm sure there must be other complex cross-referencing cases along these lines. I'd also like to hear from others what they think of this level of testing. For now I will disable along with other experimental features, but we could bring it back, given evidence of sufficient testing. Regards, Maciej Simple examples (no deep referencing): use-on-g-containing-use.svg use-on-g.svg use-on-rect.svg use-on-symbol-inside-pattern.svg use-on-symbol.svg use-on-text.svg use-on-use.svg The usual suspects: simple tests - w/o fancy features. Misc: use-events-crash.svg use-symbol-overflow.svg use-transform.svg Other simple tests. -- I hope the on tests are quite sufficient to test the tricky parts of the new SVGUseElement / SVGElementInstance code. I'd like to invent anyone interessed to stress test the code. We're already much better than Opera/FF/Batik (yes even Batik) with the current implementation - and all it needs is heavy testing IMHO. Niko P.S. The only known problem is that the event dispatching is not completely implemented. IIRC the last missing issue is: (quote from 1.1 spec) "An element and all its corresponding SVGElementInstance objects share an event listener list. The currentTarget attribute of the event can be used to determine through which object an event listener was invoked." ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SVG Stabilization
Hey Maciej, > Seems like there is rough consensus around this plan. So I filed bugs > to disable the experimental features for now: > http://bugs.webkit.org/show_bug.cgi?id=12883 > > And to do some kind of additional testing/review of the various SVG > microsyntax parsers (it turns out there are a lot): > http://bugs.webkit.org/show_bug.cgi?id=12884 Perfect. I think this covers most cases. > Some people have suggested that should also be left on. I think > to make this possible would require significant additional testing, > including test cases of unusual situations like circular references, > nested references, etc. If anyone wants to do that testing, feel > free, and ideally please document it with test cases. Note: rewriting > in a completely different way is unlikely to make it more > suitable for prime time, since the biggest problem with it is that it > is new, relatively untested code. Agreed, it's definately new code, though the scenarios you are mentioning are covered by tests (LayoutTests/svg/custom). In detail: SVGElementInstance tests / (SVG) DOM scripting: use-elementInstance-event-target.svg use-elementInstance-methods.svg use-instanceRoot-modifications.svg use-modify-container-in-target.svg use-modify-target-container.svg use-modify-target-symbol.svg use-property-changes-through-dom.svg use-property-changes-through-svg-dom.svg All of these tests operate on the new SVGElementInstance interfaces. (instanceRoot method of SVGUseElement, returns the root SVGElementInstance). The built SVGElementInstance tree is tested automatically within use-elementInstance-methods.svg (checks instance tree consistency) event handling on : use-event-handler-on-referenced-element.svg use-event-handler-on-use-element.svg Tests the various ways to set up event listeners on elements: either on the element itself, or on the referenced element. events have to be propagated to the SVGElementInstance (!) object, not the original referenced element, nor our internal clone. on tests: use-forward-refs.svg use-recursion-1.svg ( on which references the itself again.) use-recursion-2.svg ( direct self-referencing> use-recursion-3.svg ( on , containing a which references itself) use-recursion-4.svg (same like -3.svg, but one level deeper referencing) This covers the "hairy" parts. Complex deep references, circular references, self-references. All test work excellent w/o crashs or leaks. Simple examples (no deep referencing): use-on-g-containing-use.svg use-on-g.svg use-on-rect.svg use-on-symbol-inside-pattern.svg use-on-symbol.svg use-on-text.svg use-on-use.svg The usual suspects: simple tests - w/o fancy features. Misc: use-events-crash.svg use-symbol-overflow.svg use-transform.svg Other simple tests. -- I hope the on tests are quite sufficient to test the tricky parts of the new SVGUseElement / SVGElementInstance code. I'd like to invent anyone interessed to stress test the code. We're already much better than Opera/FF/Batik (yes even Batik) with the current implementation - and all it needs is heavy testing IMHO. Niko P.S. The only known problem is that the event dispatching is not completely implemented. IIRC the last missing issue is: (quote from 1.1 spec) "An element and all its corresponding SVGElementInstance objects share an event listener list. The currentTarget attribute of the event can be used to determine through which object an event listener was invoked." ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SVG Stabilization
Hi everyone, Seems like there is rough consensus around this plan. So I filed bugs to disable the experimental features for now: http://bugs.webkit.org/show_bug.cgi?id=12883 And to do some kind of additional testing/review of the various SVG microsyntax parsers (it turns out there are a lot): http://bugs.webkit.org/show_bug.cgi?id=12884 Some people have suggested that should also be left on. I think to make this possible would require significant additional testing, including test cases of unusual situations like circular references, nested references, etc. If anyone wants to do that testing, feel free, and ideally please document it with test cases. Note: rewriting in a completely different way is unlikely to make it more suitable for prime time, since the biggest problem with it is that it is new, relatively untested code. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SVG Stabilization
On 2/24/07, Nikolas Zimmermann <[EMAIL PROTECTED]> wrote: > 2) Additional testing >* Fuzz-test for custom parsers - the biggest security risk is > buffer overruns in some of the custom parsers, so we'd like to > develop a fuzz-testing tool for attributes that trigger these, and > fix resulting crashes. Definately. There have been too many crashes around involving the svg path parsing code etc. Any idea how to develop such a fuzz-testing tool? Simple perl/ruby/ script producing static test files? You might try http://sam.zoy.org/zzuf/ - I never tried it but from the description it seems to fit the bill perfectly. -- kjk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SVG Stabilization
Hey Maciej, sorry for the really late reply. But I forgot to send the reply :/ First of all I'm very happy to see there is real interesst in a WebKit release with SVG included - after all that's why me/Rob started to work on WebKit as our main code base :-) > To address these concerns, a few of us came up with a plan which I'd > like to propose now for discussion. I would especially like to hear > from WebKit SVG hackers on this. > > 1) Disable newer/experimental features (we'd probably guard these > with a single SVG_EXPERIMENTAL_FEATURES ifdef) >* SVGImage -- already disabled >* Animation -- not tested anywhere enough yet, and still noticably > unstable >* Filters -- still unstable, and can cause problems with buggy > graphics drivers which take down the whole machine >* Use -- untested/unstable >* foreignObject -- might have issues with html inside svg, > particularly for hit testing, etc > I totally agree with disabling SVGImage/Animation/Filters/foreignObject, for several reasons: Animation is not even finished from a designed perspective, nor would I call it a reliable implementation. Disabling is a must for a release. Filters are "fishy". They don't work correctly, they leak, have SVG DOM updating issues, and relies on some dirty hacks. Needs to be disabled, too. SVGImage was a quick hack to show "it works", and isn't really meant to be enabled yet in a stable build. foreignObject is rather untested - at least from my side. I never touched it at all, and we already have several bug reports about problems with it. So disabling is also a must here. For I see it a bit different. You're right that the code was a source of crashes lately - but mostly because of the stupid fact that I forgot the toNode() implementation (I think you've fixed it in ToT some weeks ago). I have tested it extensively when implementing it - as it's one of the most important features in SVG. We have Andreas Neumann around who stated to be happy doing a lot of more testing in the future. All the carto.net examples involving work excellent already. The SVGElementInstance support is something most viewers do NOT have, and it would be nice to have us including it in a release :-) I hope I can get you convinced that is a must - I'd be happy to fix all issues that are reported (already looking forward to Andreas mail flood ;-) > 2) Additional testing >* Fuzz-test for custom parsers - the biggest security risk is > buffer overruns in some of the custom parsers, so we'd like to > develop a fuzz-testing tool for attributes that trigger these, and > fix resulting crashes. Definately. There have been too many crashes around involving the svg path parsing code etc. Any idea how to develop such a fuzz-testing tool? Simple perl/ruby/ script producing static test files? >* XSS testing - SVG has many elements that reference external > content, these should be tested for cross-site scripting risk. Fortunately we don't allow ie / external references so far. I think there is no support at all for external referencing, except the usual: external JS scripts / external CSS sheets. Though that is using WebCore code itself - no additional SVG trickery - so that should be safe. SVGImage is disabled, so referencing external SVG content is not possible - shouldn't be a problem. Did I miss anything? >* Additional ad-hoc testing - we will need community help with this Agreed. >* Look into generating new results for pixel tests and keep them > passing, once experimental features are off on trunk. Agreed. Thanks for getting the discussion started, Maciej! Short resume: I agree with all points of your mail, except for . That needs further discussion :-) Niko ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SVG Stabilization
On 2/21/07, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: >Have you tried using a static checker for these? We're looking into applying a static checker for all of WebKit; we need to work out the logistics, to make sure there are up-to-date results regularly available to the community. I can recommend Coverity (if you can afford it). In my experience it works quite well. -- kjk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SVG Stabilization
On 22-Feb-07, at 1:22 AM, Maciej Stachowiak wrote: 2) Additional testing * Fuzz-test for custom parsers - the biggest security risk is buffer overruns in some of the custom parsers, so we'd like to develop a fuzz-testing tool for attributes that trigger these, and fix resulting crashes. It's a bit worrisome that we could still have issues like this. On the one hand, all browsers have uncaught security holes. But on the other hand, some of the SVG code is indeed less tested and less hardened than other portions of the code, which is why we are considering disabling some of it and want to do additional automated and manual testing. I think we need to make better use of tools like fuzz testers and static checkers over time. With BuildBot, it's relatively simple to add more kinds of automated testing that happens on every checkin. Also: I'm regularly running Valgrind on it, but now that we have a Qt buildbot we could actually set that up to do runs with valgrind too. I did that with another project before and it worked very nicely. -- George Staikos KDE Developer http://www.kde.org/ Staikos Computing Services Inc. http://www.staikos.net/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SVG Stabilization
On Feb 21, 2007, at 8:12 AM, George Staikos wrote: On 20-Feb-07, at 3:13 AM, Maciej Stachowiak wrote: As part of our stabilization effort, SVG has been raised as an area of concern. Some of the newer SVG features have been sources of crashes, some of which could potentially be security issues (the ones that are buffer overruns). Specifically, here are some of the risks we see from SVG in our current state: * Non-security hole crashes in normal SVG content on the web - may affect user perception of quality, but SVG content is not yet very common. * Security holes - potentially exploitable buffer overruns and such. These are really bad, because anyone that shipped an engine exposing these would be forced to issue high priority security updates as they get discovered. SVG content being relatively rare will not help Have you tried using a static checker for these? We're looking into applying a static checker for all of WebKit; we need to work out the logistics, to make sure there are up-to-date results regularly available to the community. 2) Additional testing * Fuzz-test for custom parsers - the biggest security risk is buffer overruns in some of the custom parsers, so we'd like to develop a fuzz-testing tool for attributes that trigger these, and fix resulting crashes. It's a bit worrisome that we could still have issues like this. On the one hand, all browsers have uncaught security holes. But on the other hand, some of the SVG code is indeed less tested and less hardened than other portions of the code, which is why we are considering disabling some of it and want to do additional automated and manual testing. I think we need to make better use of tools like fuzz testers and static checkers over time. With BuildBot, it's relatively simple to add more kinds of automated testing that happens on every checkin. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SVG Stabilization
Andreas, More testing would be great! Our existing tests are in LayoutTests/svg/. They include the W3C tests, version 1.1. You can run our tests with the run-webkit-tests script, passing it --pixel to generate pixel results. I don't think pixel tests work very well for SVG right now, so you probably just want to verify your results in the browser. More information is, of course, available at webkit.org and on #webkit on the irc.freenode.net IRC server. I would recommend adding unit tests to LayoutTests/svg/ on a feature by feature basis, starting with the features that you see as most important. As you probably know, it's important for tests to cover default behavior as well as edge cases. Edge cases for attributes includes no value, an empty string, 1 above and 1 below a numeric limit, very huge positive and negative numbers, very long strings, etc. Edge cases for elements includes use in incorrect context, CSS cascading, overflow, scrolling, and dynamic movement through JavaScript. Edge cases for both includes dynamic insertion and removal through JavaScript. I'm sure you can think of more. We also want to test SVG in different contexts: , , . As far as timeframe is concerned, we can't comment specifically on the next Apple release of WebKit, but we are hard at work on stabilizing WebKit in order to make it suitable for release. Thanks, Geoff I volunteer to do testing regarding the element. Webkit would be the only major browser/UA that doesn't support , which would be limiting content wise. This doesn't mean that is correctly implemented everywhere. Regarding 2) I also volunteer to do more testing. What is the timeframe for releasing webkit? When do you need the testing? I guess ASAP? There will also be more test cases in the upcoming SVG testsuite regarding the element. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SVG Stabilization
On 21 Feb 2007, at 17:12, George Staikos wrote: Have you tried using a static checker for these? good question. It's a bit worrisome that we could still have issues like this. from what i understand the svg path parser code among other parts is relatively new. more review is probably always welcome. Alex --- Alexander Kellett PGP - 0x6BFA8EF3, FPR: DA65 D6DE 56A9 D715 EFB6 A948 B2EF 6622 6BFA 8EF3 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SVG Stabilization
On 20-Feb-07, at 3:13 AM, Maciej Stachowiak wrote: As part of our stabilization effort, SVG has been raised as an area of concern. Some of the newer SVG features have been sources of crashes, some of which could potentially be security issues (the ones that are buffer overruns). Specifically, here are some of the risks we see from SVG in our current state: * Non-security hole crashes in normal SVG content on the web - may affect user perception of quality, but SVG content is not yet very common. * Security holes - potentially exploitable buffer overruns and such. These are really bad, because anyone that shipped an engine exposing these would be forced to issue high priority security updates as they get discovered. SVG content being relatively rare will not help Have you tried using a static checker for these? 2) Additional testing * Fuzz-test for custom parsers - the biggest security risk is buffer overruns in some of the custom parsers, so we'd like to develop a fuzz-testing tool for attributes that trigger these, and fix resulting crashes. It's a bit worrisome that we could still have issues like this. -- George Staikos KDE Developer http://www.kde.org/ Staikos Computing Services Inc. http://www.staikos.net/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SVG Stabilization
Hi everyone, Maciej, On 20 févr. 2007, at 10:12, Andreas Neumann wrote: From your list in 1) I agree that SVGImage, Animation, Filters and ForeignObject probably need more effort and testing and they are candidates to be disabled. This also matches what Firefox can do today. However, the support of the element is very important. is widely used in SVG content out there and I would welcome it if it could make it into the next main Webkit version, even if this means additional efforts from your side. I volunteer to do testing regarding the element. Webkit would be the only major browser/UA that doesn't support , which would be limiting content wise. This doesn't mean that is correctly implemented everywhere. I agree with Andreas. Although it is a bit of a shame that advanced features such as SVGImage, animation, filters and foreignObject won't be supported in the stable WebKit, it is a fact of life that I assume we have to live with for the time being. However, is a feature you'll often encounter in SVG content given that both Opera and Firefox have supported this feature from their first release supporting SVG onwards. If any kind of push is required on a single feature at risk for stable, it should definitely be this one. Sorry to say that I can't commit resources in terms of making it happen, but I thought I'd voice my support for Andreas's opinion. Antoine -- Blog — http://the.fuchsia-design.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SVG Stabilization
Hello Maciej and others, I am not a Webkit SVG developer, but a SVG developer and webkit user. I think it is important that SVG is turned on in Webkit. The main reason that SVG isn't widely used today is the fact that some major browsers don't support it. So please turn it on but disable experimental features. From your list in 1) I agree that SVGImage, Animation, Filters and ForeignObject probably need more effort and testing and they are candidates to be disabled. This also matches what Firefox can do today. However, the support of the element is very important. is widely used in SVG content out there and I would welcome it if it could make it into the next main Webkit version, even if this means additional efforts from your side. I volunteer to do testing regarding the element. Webkit would be the only major browser/UA that doesn't support , which would be limiting content wise. This doesn't mean that is correctly implemented everywhere. Regarding 2) I also volunteer to do more testing. What is the timeframe for releasing webkit? When do you need the testing? I guess ASAP? There will also be more test cases in the upcoming SVG testsuite regarding the element. Thank you for considering my feedback. Andreas Maciej Stachowiak wrote: Hi Everyone, As part of our stabilization effort, SVG has been raised as an area of concern. Some of the newer SVG features have been sources of crashes, some of which could potentially be security issues (the ones that are buffer overruns). Specifically, here are some of the risks we see from SVG in our current state: * Non-security hole crashes in normal SVG content on the web - may affect user perception of quality, but SVG content is not yet very common. * Security holes - potentially exploitable buffer overruns and such. These are really bad, because anyone that shipped an engine exposing these would be forced to issue high priority security updates as they get discovered. SVG content being relatively rare will not help * Sites developing a dependency on WebKit-specific SVG bugs - we are not as worried about this, since there are a number of other SVG implementations out there, and Gecko at least has more market share. To address these concerns, a few of us came up with a plan which I'd like to propose now for discussion. I would especially like to hear from WebKit SVG hackers on this. 1) Disable newer/experimental features (we'd probably guard these with a single SVG_EXPERIMENTAL_FEATURES ifdef) * SVGImage -- already disabled * Animation -- not tested anywhere enough yet, and still noticably unstable * Filters -- still unstable, and can cause problems with buggy graphics drivers which take down the whole machine * Use -- untested/unstable * foreignObject -- might have issues with html inside svg, particularly for hit testing, etc 2) Additional testing * Fuzz-test for custom parsers - the biggest security risk is buffer overruns in some of the custom parsers, so we'd like to develop a fuzz-testing tool for attributes that trigger these, and fix resulting crashes. * XSS testing - SVG has many elements that reference external content, these should be tested for cross-site scripting risk. * Additional ad-hoc testing - we will need community help with this * Look into generating new results for pixel tests and keep them passing, once experimental features are off on trunk. Thoughts? Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev -- -- Andreas Neumann Institute of Cartography ETH Zurich Wolfgang-Paulistrasse 15 CH-8093 Zurich, Switzerland Phone: ++41-44-633 3031, Fax: ++41-44-633 1153 e-mail: [EMAIL PROTECTED] www: http://www.carto.net/neumann/ SVG.Open: http://www.svgopen.org/ Carto.net: http://www.carto.net/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SVG Stabilization
no idea how much my vote counts in this area anymore :) but i fully agree with the ideas expressed in this mail Alex On 20 Feb 2007, at 03:13, Maciej Stachowiak wrote: Hi Everyone, As part of our stabilization effort, SVG has been raised as an area of concern. Some of the newer SVG features have been sources of crashes, some of which could potentially be security issues (the ones that are buffer overruns). Specifically, here are some of the risks we see from SVG in our current state: * Non-security hole crashes in normal SVG content on the web - may affect user perception of quality, but SVG content is not yet very common. * Security holes - potentially exploitable buffer overruns and such. These are really bad, because anyone that shipped an engine exposing these would be forced to issue high priority security updates as they get discovered. SVG content being relatively rare will not help * Sites developing a dependency on WebKit-specific SVG bugs - we are not as worried about this, since there are a number of other SVG implementations out there, and Gecko at least has more market share. To address these concerns, a few of us came up with a plan which I'd like to propose now for discussion. I would especially like to hear from WebKit SVG hackers on this. 1) Disable newer/experimental features (we'd probably guard these with a single SVG_EXPERIMENTAL_FEATURES ifdef) * SVGImage -- already disabled * Animation -- not tested anywhere enough yet, and still noticably unstable * Filters -- still unstable, and can cause problems with buggy graphics drivers which take down the whole machine * Use -- untested/unstable * foreignObject -- might have issues with html inside svg, particularly for hit testing, etc 2) Additional testing * Fuzz-test for custom parsers - the biggest security risk is buffer overruns in some of the custom parsers, so we'd like to develop a fuzz-testing tool for attributes that trigger these, and fix resulting crashes. * XSS testing - SVG has many elements that reference external content, these should be tested for cross-site scripting risk. * Additional ad-hoc testing - we will need community help with this * Look into generating new results for pixel tests and keep them passing, once experimental features are off on trunk. Thoughts? Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev --- Alexander Kellett PGP - 0x6BFA8EF3, FPR: DA65 D6DE 56A9 D715 EFB6 A948 B2EF 6622 6BFA 8EF3 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
