Comment by intrasight

3 months ago

It is a balance (compatibility vs attach surfaces). The issue with XSLT (which I am still a strong advocate for) is that nobody is maintaining that code. So vulnerabilities sit there undetected. Like the relatively recent discovery of the xsl:document vulnerability.

> It is a balance (compatibility vs attach surfaces).

What I'm trying to say is that it's a false dichotomy in most cases: implementations could almost eliminate the attack surface while maintaining the same functionality, and without devoting any more ongoing effort. Such as, for instance, JS polyfills, or WASM blobs, which could be subjected to the usual security boundaries no matter how bug-ridden and ill-maintained they are internally.

But removing the functionality is often seen as the more expedient option, and so that's what gets picked.

  • Sure, but this requires someone sitting down and writing the JS polyfill, and then maintaining it indefinitely. And for something as complicated as XSLT, that will surely be indefinite maintenance, because complicated specs beget complicated implementations.

    In the absence of anyone raring to do that, removal seems the more sensible option.

    • The vendor discussion on removing XSLT is predicated on someone creating a polyfill for users to move to. It is not an unreasonable assumption because a polyfill can be created fairly trivially by compiling the existing XSLT processor to WASM.

      And it is also fairly trivial to put that polyfill into the browsers.

      The Chrome team has been moaning about XSLT for a decade. If security was really their concern they could have replaced the implementation with asm.js a decade ago, just as they did for pdfs.

    • > Sure, but this requires [...] maintaining it indefinitely.

      Does it, though? Browsers already have existing XSLT stacks, which have somehow gotten by practically unmodified for the last 20 years. The basic XSLT 1.0 functionality never changes, and the links between the XSLT code and the rest of the codebase rarely change, so I find it hard to believe that slapping it into a sandbox would suddenly turn it into a persistent time sink.

      2 replies →