On Aug 20, 2013, at 7:02 PM, Martin Owens wrote:
On Wed, 2013-08-21 at 03:48 +0200, Krzysztof Kosiński wrote:
use libxml2's SAX parser
This sounds like the right direction to take considering the bug and the pickle we're in between the vuln and the support for xml made in other applications.
I only have three questions:
- What difference (if any) in compile and/or run-time requirements
- How messy would a transition be from the dom parser to libxml2?
- How long would it take to do the transition?
There might be some lingering code that expects libxml's dom nodes to be present... but that is something we should look into anyway.
In general if switching parsers would be a good thing, then the conversion can be done without *too* much work. Or more specifically I can probably address that. I've used SAX with Java, libxml and others for some time now, and can get most of what we need covered. So...
1. Compile time and run-time should be the same. Both API's have been part of core libxml2.
2. Depends on whether or not our code depends on the libxml DOM tree to remain present after initial parsing.
3. If the existing DOM parser is just used for throw-away input, then I can probably get it done in a few days... so call it three weeks. :-)
Of course, if we do have the DOM tree left over, we most likely want to purge that anyway. In the long run I definitely see shifting to a SAX parser as a good step. It will bring in other benefits also, such as making it easier to support multiple versions of SVG, broken SVG, etc.