4 ms·

> The XML parts of our pipeline are in maintenance mode and we would love to eventually deprecate and remove them, or at least replace them with something that

by jarym 6y ago

> The XML parts of our pipeline are in maintenance mode and we would love to eventually deprecate and remove them, or at least replace them with something that generates less security bugs. Increasing the capabilities of XML in the browser runs counter to that goal. Bit of a weird comment from Chrome. 'XML' doesn't generate 'security bugs' - sloppy development practices do. If they want to generate less security bugs they should be more aggressive with their testing/fuzzing in the parts of code that deal with XML.

masklinn 6y ago
> Bit of a weird comment from Chrome. 'XML' doesn't generate 'security bugs' - sloppy development practices do. That's… only true in the sense that C doesn't generate security bugs either. There are environments, systems and standards which are much more bug-prone than others, for various reasons. And XML is one of them. Not only does it literally specify and embed security issues (so you have to break the standard to fix some of that stuff), it is a pretty complex standard, and because it is a somewhat inefficient format implementors are more likely to need to optimise the pipeline, which is difficult, and leads to more security risks. By all measures, XML is very error prone and its history is littered in security bugs in way few formats even compete. It's not the worst (I've heard a lot of bad things about ASN.1, which is made worse by ASN.1 generally having to be parsed in security contexts) but as a shortcut "XML generates security bugs" is completely fair.
- rleigh 6y ago
  There is also the matter of implementation quality and robustness, and the future of XML as a supported technology. XML technology is over 20 years old, and mainstream support for it has been slowly declining. If you're writing in any language other than Java, you don't have any good choices if you want to use more than the basic SAX/DOM APIs, and all of the available libraries have significant drawbacks if you want to do anything more than the bare essentials. I can fully understand why projects want to drop their existing XML dependencies where possible, and shy away from picking up new ones. If you're writing a product using C or C++, then you've got few choices: Apache Xerces-C and Xalan-C for XML and XSLT/XPATH, respectively. Or libxml/libxslt. Neither of these is a good choice (for the record, I'm involved with both Apache projects on an ad-hoc basis). Or QtXml/QtXmlPatterns. There are others but they aren't worth writing about. The Apache projects had pretty comprehensive support for the earlier XML and XSLT/XPATH standards, and matched the Java implementations pretty closely. But with the waning interest in XML, and the huge amounts of technical debt involved, both projects have been in maintenance mode for the last decade. No one wants to break compatibility with significant rework. Then there's the GNOME-derived libxml/libxslt. A little more modern but C-only, and lacking most of the features provided by the Apache implementation. OK if a simple subset is sufficient, but otherwise not viable. The Qt libraries are good, but it's a very heavy dependency and is again a subset of the Apache functionality, and is XSLT2 only. When it comes to adding in XPATH 2.0, there just isn't the maintainer interest available, primarily because there's no corporate interest in taking any of these projects forward in any meaningful way. XML is no longer cool or interesting, and as such projects are not willing to spend time and money on maintaining these codebases. They are all, to varying degrees, in maintenance mode. I previously worked on a large project that for various reasons, including jumping on the bandwagon of the moment, heavily opted into using XML, XSLT and using as many obscure features as possible. Being Java based, it had access to jars for doing pretty much any XML processing it liked. If the core functionality provided by the JDK isn't enough, you've got Saxon and other implementations readily to hand. I had to port a subset of the functionality to C++, and the only possibilities were Xerces+Xalan. libxml/libxslt simply didn't have the featureset for all of the obscure XML processing features needed, or all the EXSLT functions. Needing to depend upon a pair of obsolete, essentially unmaintained and difficult to use libraries is why I ended up involved in their maintenance. I later added Qt support as an alternative, but at the expense of having to disable a huge amount of core functionality. I'd like nothing more than to dump the lot of them. It's also worth pointing out that the root of the problem here is the absurd complexity of all of the (many) XML standards and APIs. A fairly simple concept which has so much complex stuff layered upon and grafted onto it that it's not really much of a wonder that it's in such of a poor state. It should have been kept simple.
barumi 6y ago
> Bit of a weird comment from Chrome. 'XML' doesn't generate 'security bugs' It seems you failed to either read or understand the comment, and meanwhile were also too eager to post snarky comments. If you pay attention to the argument that was actually made, the commenter mentioned specifically "everything implemented using libxml and libxslt". Meanwhile, here's a list of libxml security issues: * https://www.cvedetails.com/vulnerability-list/vendor_id-1962/product_id-3311/Xmlsoft-Libxml2.html https://www.cvedetails.com/vulnerability-list/vendor_id-1962... Here's a list of security issues affecting libxslt: * https://www.cvedetails.com/vulnerability-list/vendor_id-1962/product_id-14676/Xmlsoft-Libxslt.html https://www.cvedetails.com/vulnerability-list/vendor_id-1962... OP's point is very clear: if they could remove support for this feature, any of this vulnerabilities, past, present and future, would vanish.

by jarym 6y ago

masklinn 6y ago

> Bit of a weird comment from Chrome. 'XML' doesn't generate 'security bugs' - sloppy development practices do. That's… only true in the sense that C doesn't generate security bugs either. There are environments, systems and standards which are much more bug-prone than others, for various reasons. And XML is one of them. Not only does it literally specify and embed security issues (so you have to break the standard to fix some of that stuff), it is a pretty complex standard, and because it is a somewhat inefficient format implementors are more likely to need to optimise the pipeline, which is difficult, and leads to more security risks. By all measures, XML is very error prone and its history is littered in security bugs in way few formats even compete. It's not the worst (I've heard a lot of bad things about ASN.1, which is made worse by ASN.1 generally having to be parsed in security contexts) but as a shortcut "XML generates security bugs" is completely fair.

rleigh 6y ago
There is also the matter of implementation quality and robustness, and the future of XML as a supported technology. XML technology is over 20 years old, and mainstream support for it has been slowly declining. If you're writing in any language other than Java, you don't have any good choices if you want to use more than the basic SAX/DOM APIs, and all of the available libraries have significant drawbacks if you want to do anything more than the bare essentials. I can fully understand why projects want to drop their existing XML dependencies where possible, and shy away from picking up new ones. If you're writing a product using C or C++, then you've got few choices: Apache Xerces-C and Xalan-C for XML and XSLT/XPATH, respectively. Or libxml/libxslt. Neither of these is a good choice (for the record, I'm involved with both Apache projects on an ad-hoc basis). Or QtXml/QtXmlPatterns. There are others but they aren't worth writing about. The Apache projects had pretty comprehensive support for the earlier XML and XSLT/XPATH standards, and matched the Java implementations pretty closely. But with the waning interest in XML, and the huge amounts of technical debt involved, both projects have been in maintenance mode for the last decade. No one wants to break compatibility with significant rework. Then there's the GNOME-derived libxml/libxslt. A little more modern but C-only, and lacking most of the features provided by the Apache implementation. OK if a simple subset is sufficient, but otherwise not viable. The Qt libraries are good, but it's a very heavy dependency and is again a subset of the Apache functionality, and is XSLT2 only. When it comes to adding in XPATH 2.0, there just isn't the maintainer interest available, primarily because there's no corporate interest in taking any of these projects forward in any meaningful way. XML is no longer cool or interesting, and as such projects are not willing to spend time and money on maintaining these codebases. They are all, to varying degrees, in maintenance mode. I previously worked on a large project that for various reasons, including jumping on the bandwagon of the moment, heavily opted into using XML, XSLT and using as many obscure features as possible. Being Java based, it had access to jars for doing pretty much any XML processing it liked. If the core functionality provided by the JDK isn't enough, you've got Saxon and other implementations readily to hand. I had to port a subset of the functionality to C++, and the only possibilities were Xerces+Xalan. libxml/libxslt simply didn't have the featureset for all of the obscure XML processing features needed, or all the EXSLT functions. Needing to depend upon a pair of obsolete, essentially unmaintained and difficult to use libraries is why I ended up involved in their maintenance. I later added Qt support as an alternative, but at the expense of having to disable a huge amount of core functionality. I'd like nothing more than to dump the lot of them. It's also worth pointing out that the root of the problem here is the absurd complexity of all of the (many) XML standards and APIs. A fairly simple concept which has so much complex stuff layered upon and grafted onto it that it's not really much of a wonder that it's in such of a poor state. It should have been kept simple.

barumi 6y ago

> Bit of a weird comment from Chrome. 'XML' doesn't generate 'security bugs' It seems you failed to either read or understand the comment, and meanwhile were also too eager to post snarky comments. If you pay attention to the argument that was actually made, the commenter mentioned specifically "everything implemented using libxml and libxslt". Meanwhile, here's a list of libxml security issues: * https://www.cvedetails.com/vulnerability-list/vendor_id-1962/product_id-3311/Xmlsoft-Libxml2.html https://www.cvedetails.com/vulnerability-list/vendor_id-1962... Here's a list of security issues affecting libxslt: * https://www.cvedetails.com/vulnerability-list/vendor_id-1962/product_id-14676/Xmlsoft-Libxslt.html https://www.cvedetails.com/vulnerability-list/vendor_id-1962... OP's point is very clear: if they could remove support for this feature, any of this vulnerabilities, past, present and future, would vanish.