6 ms·

PSA: Libxslt is unmaintained and has 5 unpatched security bugs

136 points by burnt-resistor 1y ago

burnt-resistor 1y ago
Update 0: Fixed title, it's 5 rather than 4, and possibly another that's undisclosed. Update 1: Apparently, GNOME bureaucracy is holding up the processing the application of a new maintainer for over a month now. Major browsers responded by deprecating/removing XSLT support. XSLT is/was mainly used for rendering and transforming SGML, HTML, and XML to other forms, I didn't even realize browsers supported it directly. https://gitlab.gnome.org/GNOME/libxslt/-/issues/150 https://gitlab.gnome.org/GNOME/libxslt/-/issues/150 --- List 0: https://gitlab.gnome.org/GNOME/libxslt/-/issues/139 https://gitlab.gnome.org/GNOME/libxslt/-/issues/139 1: https://gitlab.gnome.org/GNOME/libxslt/-/issues/140 https://gitlab.gnome.org/GNOME/libxslt/-/issues/140 2: https://gitlab.gnome.org/GNOME/libxslt/-/issues/144 https://gitlab.gnome.org/GNOME/libxslt/-/issues/144 3: https://gitlab.gnome.org/GNOME/libxslt/-/issues/148 https://gitlab.gnome.org/GNOME/libxslt/-/issues/148 4: BIGSLEEP-433713988 https://issuetracker.google.com/issues/433713988 https://issuetracker.google.com/issues/433713988 > Please be aware: nobody will merge your fix because there are no active maintainers remaining. (If anybody is interested in maintaining libxslt, please let me know.) Having patches here will help a lot anyway, though, since downstream vendors will be able to use them. https://gitlab.gnome.org/GNOME/libxslt/-/issues/144#note_2459277 https://gitlab.gnome.org/GNOME/libxslt/-/issues/144#note_245... List of FreeBSD ports that are unlikely to build without `make DISABLE_VULNERABILITIES=yes`: https://pastebin.com/raw/5dQ2U46f https://pastebin.com/raw/5dQ2U46f I guess, technically, if libxslt isn't statically or dynamically linked in like browsers and some other programs do and only used as a build dep such as through xsltproc, there's not really a security issue after a build. For all runtime use / direct linking of libxslt, it's still a problem.
- bawolff 1y ago
  > Major browsers responded by deprecating/removing XSLT support Its probably wrong to think the browser stuff is solely due to lack of maintainer.
  - ZiiS 1y ago
    Not directly, but if the most used implementation is unmaintained how popular is the language?
    - sitharus 1y ago
      These days? Not very. However a lot of systems created in the 2000s, particularly enterprise software because XML was seen as the thing for enterprises, depends on it. It’s not (and never was outside of corporate webapps) very common on the web, but there are still legacy things that need it.
    - bawolff 1y ago
      Its a niche domain specific programming language. Its fairly popular in its niche (i.e. transforming xml documents to other formats), but that niche is kind of dying as xml wanes in popularity. There are definitely still users, although a lot of them are probably outside the browser.
      - antonvs 1y ago
        I did some work with XSLT back when it was enjoying some popularity (i.e. > 20 years ago.) While I understand the appeal of the concepts behind XSLT, a language like that being expressed in XML is just... unfathomably perverse. It's a positive testament to the industry's taste that XSLT essentially died.
- bkor 1y ago
  > Update 1: Apparently, GNOME bureaucracy is holding up the processing the application of a new maintainer for over a month now. Could you explain this? You link to a closed bugreport where a new maintainer stepped up. A previously experienced developer said it'll take several months at least to get up to speed. That a new person needs to be vouched for a critical library is pretty critical. There's been several examples where a malicious developer took over a critical project.
- mjw1007 1y ago
  It's clear from that bug tracker that you shouldn't let libxlst see untrusted stylesheets or xpath expressions. I haven't yet seen a problem with running your own transformations against untrusted XML. Maybe a new maintainer could aim to make the second case fully supported but not the first.
- chrismorgan 1y ago
  > Major browsers responded by deprecating/removing XSLT support. This is not true. They’re investigating doing that. There is no actual deprecation yet, and even if they do decide to deprecate and then remove, I imagine the process would take at least a couple of years. The first actual major feature removal from the web would be a big deal. Blink declared intent to deprecate and remove XSLT in both 2013 and 2015, but gave up on them each time. My feeling is that both sides may actually be stronger this time—browser makers more intent on removing it, and objections louder too. A decade ago, Google tried to kill MathML in not entirely dissimilar circumstances—though in that case they didn’t even have a shipping implementation themselves. When the dust settled, MathML Core was a thing, and Igalia had implemented it in Chromium. It wouldn’t surprise me if they do end up removing XSLT, but it also wouldn’t surprise me if we actually ended up with a new commitment to XSLT and XSLT 3.0 support out of this commotion. That’s what I’m hoping for.
- acdha 1y ago
  > Apparently, GNOME bureaucracy is holding up the processing the application of a new maintainer for over a month now. This wording seems unjustly negative. You’re talking about software which is shipped in every browser, all Linux distributions, and bundled in a ton of languages. A short delay doesn’t seem unwarranted for key bits of infrastructure.
imp0cat 1y ago
Does this affect https://lxml.de/ https://lxml.de/ ?
- _zagj 1y ago
  Yes, as it's a front-end to both LibXML2 and LibXSLT.
  - throwaway290 1y ago
    There's A LOT downstream then
MangoToupe 1y ago
[flagged]
- therein 1y ago
  I always thought of it as a specialized XML extension that describes transformations on other XML documents. Never used it, not sure why anything on my system uses it if I don't come across it in my daily software development life either but I have seen it as a dependency more times than I can remember.
- alexjplant 1y ago
  XSLT is a declarative language for transforming XML to other formats. XML is a pretty poor solution for configuration files (which is what everybody seemed to use it for back in the day) but works great for, you guessed it, marking up documents. If you have an XML schema for representing documents semantically you can then write an XSLT that quickly and efficiently converts it to, say, XHTML. This way you can work in a nice intermediate representation rich with meaning and specify the presentation as a function thereof. It's not particularly sexy technology but it works well when used judiciously. Part of me wonders if XML will make some bizarre comeback in the era of LLMs for training data annotation or something similarly niche.
  - MangoToupe 1y ago
    Ok, but my question stands. What value does this provide society?
    - jamesnorden 1y ago
      What value do you provide society?
      - MangoToupe 1y ago
        How is this relevant to figuring out why xml document transformations exist? I feed my family.
Svip 1y ago
Related: "Remove mentions of XSLT from the html spec" (9 days ago, 388p, 534c) https://news.ycombinator.com/item?id=44952185 https://news.ycombinator.com/item?id=44952185 "XSLT removal will break multiple government and regulatory sites" (6 days ago, 157p, 142c) https://news.ycombinator.com/item?id=44987346 https://news.ycombinator.com/item?id=44987346 "Should the web platform adopt XSLT 3.0?" (6 days ago, 133p, 107c) https://news.ycombinator.com/item?id=44987552 https://news.ycombinator.com/item?id=44987552 "Google did not unilaterally decide to kill XSLT" (6 days ago, 102p, 130c) https://news.ycombinator.com/item?id=44987239 https://news.ycombinator.com/item?id=44987239
camgunz 1y ago
Am I right that, while we can't have SQLite because there's only 1 implementation, we can have XSLT even though there's only 1--unmaintained--implementation?
- bryanrasmussen 1y ago
  What are you talking about? There are many maintained implementations of XSLT at various levels compliance and versions. The problem is libxslt is built on top of libxml, and libxml is being used for a bunch of stuff through browsers etc. And that it is a C implementation which most others aren't, actually I say most but not sure if there is a C implementation other than libxslt.
- simonw 1y ago
  Firefox uses TransforMiiX. Historically, MSIE used MSXML and Opera used their own custom engine until they both moved to Blink which uses libxslt.
- foul 1y ago
  Nah, libxslt is a spinoff of Expat, at the very least (and mozilla mantains its own xslt library) there's a full implementation by the standard writer called Saxon[0] [0] https://www.saxonica.com/saxon-c/index.xml https://www.saxonica.com/saxon-c/index.xml
- tannhaeuser 1y ago
  That's at least not something you can accuse XLST 1.0 of. Like most parts of the old "XML stack", XLST 1.0 has ample implementations in Xalan/C, Xalan/J, Saxon, libxslt2, MS XML, to name only mainstream ones. And the portability for XLST 1.0 is almost perfect/gives identical results (up to DOM equivalency eg. attribute ordering, and even beyond) in my experience. XSLT 2.x/3.y however, while still a "W3C recommendation", violates (or had violated for the longest time) W3C's own policy of at least two interworking implementations to reach "recommendation" stage, and is authored by the vendor of the single XSLT 2.0/3.0 product, which used to be a problem I pointed out several times. Of course, nobody cares about W3C, Inc. anymore, precisely because of those pay-as-you-go and other self-serving policies among other things.
JimDabell 1y ago
Also see: > Finding and exploiting 20-year-old bugs in web browsers > Although XSLT in web browsers has been a known attack surface for some time, there are still plenty of bugs to be found in it, when viewing it through the lens of modern vulnerability discovery techniques. In this presentation, we will talk about how we found multiple vulnerabilities in XSLT implementations across all major web browsers. We will showcase vulnerabilities that remained undiscovered for 20+ years, difficult to fix bug classes with many variants as well as instances of less well-known bug classes that break memory safety in unexpected ways. We will show a working exploit against at least one web browser using these bugs. — https://www.offensivecon.org/speakers/2025/ivan-fratric.html https://www.offensivecon.org/speakers/2025/ivan-fratric.html — https://www.youtube.com/watch?v=U1kc7fcF5Ao https://www.youtube.com/watch?v=U1kc7fcF5Ao
nwellnhof 1y ago
From my experience, these issues are only relevant if you allow the execution of untrusted stylesheets which nobody would ever do. The only exception are browser vendors. A couple of years ago, I had the idea of funding libxslt development with Google Chrome bug bounties. This was cut short after reporting two or three issues. Google refused to pay bounties for valid reports because I was a contributor to libxslt, regardless of whether these bugs were 20 years old. I must admit that I feel a bit of schadenfreude. On the other hand, it still makes me sad that these companies care so little about upstream projects and OSS in general.
- Wowfunhappy 1y ago
  > Google refused to pay bounties for valid reports because I was a contributor to libxslt Huh?
  - Cyykratahk 1y ago
    I'm guessing Google is avoiding the scenario where a contributor "accidentally" commits code with a bug, then later reports the bug they "found".
    - Wowfunhappy 1y ago
      I can understand if it's code the reporting person actually wrote, but if it's just someone else on the project that seems pretty ridiculous.
      - motorest 1y ago
        Not ridiculous. It's a clear conflict of interests, and represents a perverse incentive.
        baq 1y ago
        And it’s easy to fix - sponsor a contributor. It’d be cheaper than the many meetings that were needed to make the removal decision.
grandinj 1y ago
Is this not what the Linux Foundation was about at one stage? Taking ownership of unmaintained projects so that at least they have the bare minimum of patches being applied, CI/CD running, releases being created?
- tempfile 1y ago
  That's interesting, I thought the Linux Foundation just existed to give corporations somewhere to put their money without it actually making an effective difference.
- arccy 1y ago
  While the Linux Foundation can provide some support, it's still up to each project to find their own maintainers (and pay for them).
  - grandinj 1y ago
    That is a pity. Clearly we need some kind of Home For Abandoned Code :-)
    - kstrauser 1y ago
      Isn’t that the Apache Foundation? I kid. Mostly.
      - zappb 1y ago
        That would be the Apache Attic: https://attic.apache.org/ https://attic.apache.org/
    - jve 1y ago
      And can we have bounties for fixing know CVEs in that abandoned code? Abandoned Code home should only allow security changes and if someone wants to revive the project, bump the major version and get out of abandoned code home. That is to prevent abuse by introducing new CVEs into software. While the abandoned code home hosts that piece of software for as long as some corporation wants to keep it alive with low investment. Found CVE in abandoned code and fixed yourself? Good for you, still eligible for bounty.
firesteelrain 1y ago
Relevant: https://opensourcesecurity.io/2025/08-oss-one-person/ https://opensourcesecurity.io/2025/08-oss-one-person/
SigmundA 1y ago
Looks like there is a WASM polyfill for XSLT based on libxslt: https://github.com/mfreed7/xslt_polyfill https://github.com/mfreed7/xslt_polyfill To me this is the best way forward, I used to like XSLT quite a bit but the world has moved on and I get browser maintainers not wanting to try and maintain that extra native code surface area. It seems like the browser should be incorporating many libraries as WASM to mitigate exploits and surface area such as XSLT and rarely used image formats etc. Then only do the native versions for widely used features where it's worth the effort to maintain and vet them.
notherhack 1y ago
On my system I see that libxslt is a dependency for glib, gtk+, samba, systemd, pam, and a bunch of others. That's pretty foundational. What could possibly go wrong?
- nwellnhof 1y ago
  It's only a build dependency to generate documentation with DocBook stylesheets.

Update 0: Fixed title, it's 5 rather than 4, and possibly another that's undisclosed. Update 1: Apparently, GNOME bureaucracy is holding up the processing the application of a new maintainer for over a month now. Major browsers responded by deprecating/removing XSLT support. XSLT is/was mainly used for rendering and transforming SGML, HTML, and XML to other forms, I didn't even realize browsers supported it directly. https://gitlab.gnome.org/GNOME/libxslt/-/issues/150 https://gitlab.gnome.org/GNOME/libxslt/-/issues/150 --- List 0: https://gitlab.gnome.org/GNOME/libxslt/-/issues/139 https://gitlab.gnome.org/GNOME/libxslt/-/issues/139 1: https://gitlab.gnome.org/GNOME/libxslt/-/issues/140 https://gitlab.gnome.org/GNOME/libxslt/-/issues/140 2: https://gitlab.gnome.org/GNOME/libxslt/-/issues/144 https://gitlab.gnome.org/GNOME/libxslt/-/issues/144 3: https://gitlab.gnome.org/GNOME/libxslt/-/issues/148 https://gitlab.gnome.org/GNOME/libxslt/-/issues/148 4: BIGSLEEP-433713988 https://issuetracker.google.com/issues/433713988 https://issuetracker.google.com/issues/433713988 > Please be aware: nobody will merge your fix because there are no active maintainers remaining. (If anybody is interested in maintaining libxslt, please let me know.) Having patches here will help a lot anyway, though, since downstream vendors will be able to use them. https://gitlab.gnome.org/GNOME/libxslt/-/issues/144#note_2459277 https://gitlab.gnome.org/GNOME/libxslt/-/issues/144#note_245... List of FreeBSD ports that are unlikely to build without `make DISABLE_VULNERABILITIES=yes`: https://pastebin.com/raw/5dQ2U46f https://pastebin.com/raw/5dQ2U46f I guess, technically, if libxslt isn't statically or dynamically linked in like browsers and some other programs do and only used as a build dep such as through xsltproc, there's not really a security issue after a build. For all runtime use / direct linking of libxslt, it's still a problem.

bawolff 1y ago
> Major browsers responded by deprecating/removing XSLT support Its probably wrong to think the browser stuff is solely due to lack of maintainer.
- ZiiS 1y ago
  Not directly, but if the most used implementation is unmaintained how popular is the language?
  - sitharus 1y ago
    These days? Not very. However a lot of systems created in the 2000s, particularly enterprise software because XML was seen as the thing for enterprises, depends on it. It’s not (and never was outside of corporate webapps) very common on the web, but there are still legacy things that need it.
  - bawolff 1y ago
    Its a niche domain specific programming language. Its fairly popular in its niche (i.e. transforming xml documents to other formats), but that niche is kind of dying as xml wanes in popularity. There are definitely still users, although a lot of them are probably outside the browser.
    - antonvs 1y ago
      I did some work with XSLT back when it was enjoying some popularity (i.e. > 20 years ago.) While I understand the appeal of the concepts behind XSLT, a language like that being expressed in XML is just... unfathomably perverse. It's a positive testament to the industry's taste that XSLT essentially died.
bkor 1y ago
> Update 1: Apparently, GNOME bureaucracy is holding up the processing the application of a new maintainer for over a month now. Could you explain this? You link to a closed bugreport where a new maintainer stepped up. A previously experienced developer said it'll take several months at least to get up to speed. That a new person needs to be vouched for a critical library is pretty critical. There's been several examples where a malicious developer took over a critical project.
mjw1007 1y ago
It's clear from that bug tracker that you shouldn't let libxlst see untrusted stylesheets or xpath expressions. I haven't yet seen a problem with running your own transformations against untrusted XML. Maybe a new maintainer could aim to make the second case fully supported but not the first.
chrismorgan 1y ago
> Major browsers responded by deprecating/removing XSLT support. This is not true. They’re investigating doing that. There is no actual deprecation yet, and even if they do decide to deprecate and then remove, I imagine the process would take at least a couple of years. The first actual major feature removal from the web would be a big deal. Blink declared intent to deprecate and remove XSLT in both 2013 and 2015, but gave up on them each time. My feeling is that both sides may actually be stronger this time—browser makers more intent on removing it, and objections louder too. A decade ago, Google tried to kill MathML in not entirely dissimilar circumstances—though in that case they didn’t even have a shipping implementation themselves. When the dust settled, MathML Core was a thing, and Igalia had implemented it in Chromium. It wouldn’t surprise me if they do end up removing XSLT, but it also wouldn’t surprise me if we actually ended up with a new commitment to XSLT and XSLT 3.0 support out of this commotion. That’s what I’m hoping for.
acdha 1y ago
> Apparently, GNOME bureaucracy is holding up the processing the application of a new maintainer for over a month now. This wording seems unjustly negative. You’re talking about software which is shipped in every browser, all Linux distributions, and bundled in a ton of languages. A short delay doesn’t seem unwarranted for key bits of infrastructure.

imp0cat 1y ago

Does this affect https://lxml.de/ https://lxml.de/ ?

_zagj 1y ago
Yes, as it's a front-end to both LibXML2 and LibXSLT.
- throwaway290 1y ago
  There's A LOT downstream then

MangoToupe 1y ago

[flagged]

therein 1y ago
I always thought of it as a specialized XML extension that describes transformations on other XML documents. Never used it, not sure why anything on my system uses it if I don't come across it in my daily software development life either but I have seen it as a dependency more times than I can remember.
alexjplant 1y ago
XSLT is a declarative language for transforming XML to other formats. XML is a pretty poor solution for configuration files (which is what everybody seemed to use it for back in the day) but works great for, you guessed it, marking up documents. If you have an XML schema for representing documents semantically you can then write an XSLT that quickly and efficiently converts it to, say, XHTML. This way you can work in a nice intermediate representation rich with meaning and specify the presentation as a function thereof. It's not particularly sexy technology but it works well when used judiciously. Part of me wonders if XML will make some bizarre comeback in the era of LLMs for training data annotation or something similarly niche.
- MangoToupe 1y ago
  Ok, but my question stands. What value does this provide society?
  - jamesnorden 1y ago
    What value do you provide society?
    - MangoToupe 1y ago
      How is this relevant to figuring out why xml document transformations exist? I feed my family.

Svip 1y ago

Related: "Remove mentions of XSLT from the html spec" (9 days ago, 388p, 534c) https://news.ycombinator.com/item?id=44952185 https://news.ycombinator.com/item?id=44952185 "XSLT removal will break multiple government and regulatory sites" (6 days ago, 157p, 142c) https://news.ycombinator.com/item?id=44987346 https://news.ycombinator.com/item?id=44987346 "Should the web platform adopt XSLT 3.0?" (6 days ago, 133p, 107c) https://news.ycombinator.com/item?id=44987552 https://news.ycombinator.com/item?id=44987552 "Google did not unilaterally decide to kill XSLT" (6 days ago, 102p, 130c) https://news.ycombinator.com/item?id=44987239 https://news.ycombinator.com/item?id=44987239

camgunz 1y ago

Am I right that, while we can't have SQLite because there's only 1 implementation, we can have XSLT even though there's only 1--unmaintained--implementation?

bryanrasmussen 1y ago
What are you talking about? There are many maintained implementations of XSLT at various levels compliance and versions. The problem is libxslt is built on top of libxml, and libxml is being used for a bunch of stuff through browsers etc. And that it is a C implementation which most others aren't, actually I say most but not sure if there is a C implementation other than libxslt.
simonw 1y ago
Firefox uses TransforMiiX. Historically, MSIE used MSXML and Opera used their own custom engine until they both moved to Blink which uses libxslt.
foul 1y ago
Nah, libxslt is a spinoff of Expat, at the very least (and mozilla mantains its own xslt library) there's a full implementation by the standard writer called Saxon[0] [0] https://www.saxonica.com/saxon-c/index.xml https://www.saxonica.com/saxon-c/index.xml
tannhaeuser 1y ago
That's at least not something you can accuse XLST 1.0 of. Like most parts of the old "XML stack", XLST 1.0 has ample implementations in Xalan/C, Xalan/J, Saxon, libxslt2, MS XML, to name only mainstream ones. And the portability for XLST 1.0 is almost perfect/gives identical results (up to DOM equivalency eg. attribute ordering, and even beyond) in my experience. XSLT 2.x/3.y however, while still a "W3C recommendation", violates (or had violated for the longest time) W3C's own policy of at least two interworking implementations to reach "recommendation" stage, and is authored by the vendor of the single XSLT 2.0/3.0 product, which used to be a problem I pointed out several times. Of course, nobody cares about W3C, Inc. anymore, precisely because of those pay-as-you-go and other self-serving policies among other things.

JimDabell 1y ago

Also see: > Finding and exploiting 20-year-old bugs in web browsers > Although XSLT in web browsers has been a known attack surface for some time, there are still plenty of bugs to be found in it, when viewing it through the lens of modern vulnerability discovery techniques. In this presentation, we will talk about how we found multiple vulnerabilities in XSLT implementations across all major web browsers. We will showcase vulnerabilities that remained undiscovered for 20+ years, difficult to fix bug classes with many variants as well as instances of less well-known bug classes that break memory safety in unexpected ways. We will show a working exploit against at least one web browser using these bugs. — https://www.offensivecon.org/speakers/2025/ivan-fratric.html https://www.offensivecon.org/speakers/2025/ivan-fratric.html — https://www.youtube.com/watch?v=U1kc7fcF5Ao https://www.youtube.com/watch?v=U1kc7fcF5Ao

nwellnhof 1y ago

From my experience, these issues are only relevant if you allow the execution of untrusted stylesheets which nobody would ever do. The only exception are browser vendors. A couple of years ago, I had the idea of funding libxslt development with Google Chrome bug bounties. This was cut short after reporting two or three issues. Google refused to pay bounties for valid reports because I was a contributor to libxslt, regardless of whether these bugs were 20 years old. I must admit that I feel a bit of schadenfreude. On the other hand, it still makes me sad that these companies care so little about upstream projects and OSS in general.

Wowfunhappy 1y ago
> Google refused to pay bounties for valid reports because I was a contributor to libxslt Huh?
- Cyykratahk 1y ago
  I'm guessing Google is avoiding the scenario where a contributor "accidentally" commits code with a bug, then later reports the bug they "found".
  - Wowfunhappy 1y ago
    I can understand if it's code the reporting person actually wrote, but if it's just someone else on the project that seems pretty ridiculous.
    - motorest 1y ago
      Not ridiculous. It's a clear conflict of interests, and represents a perverse incentive.
      - baq 1y ago
        And it’s easy to fix - sponsor a contributor. It’d be cheaper than the many meetings that were needed to make the removal decision.

grandinj 1y ago

Is this not what the Linux Foundation was about at one stage? Taking ownership of unmaintained projects so that at least they have the bare minimum of patches being applied, CI/CD running, releases being created?

tempfile 1y ago
That's interesting, I thought the Linux Foundation just existed to give corporations somewhere to put their money without it actually making an effective difference.
arccy 1y ago
While the Linux Foundation can provide some support, it's still up to each project to find their own maintainers (and pay for them).
- grandinj 1y ago
  That is a pity. Clearly we need some kind of Home For Abandoned Code :-)
  - kstrauser 1y ago
    Isn’t that the Apache Foundation? I kid. Mostly.
    - zappb 1y ago
      That would be the Apache Attic: https://attic.apache.org/ https://attic.apache.org/
  - jve 1y ago
    And can we have bounties for fixing know CVEs in that abandoned code? Abandoned Code home should only allow security changes and if someone wants to revive the project, bump the major version and get out of abandoned code home. That is to prevent abuse by introducing new CVEs into software. While the abandoned code home hosts that piece of software for as long as some corporation wants to keep it alive with low investment. Found CVE in abandoned code and fixed yourself? Good for you, still eligible for bounty.

firesteelrain 1y ago

Relevant: https://opensourcesecurity.io/2025/08-oss-one-person/ https://opensourcesecurity.io/2025/08-oss-one-person/

SigmundA 1y ago

Looks like there is a WASM polyfill for XSLT based on libxslt: https://github.com/mfreed7/xslt_polyfill https://github.com/mfreed7/xslt_polyfill To me this is the best way forward, I used to like XSLT quite a bit but the world has moved on and I get browser maintainers not wanting to try and maintain that extra native code surface area. It seems like the browser should be incorporating many libraries as WASM to mitigate exploits and surface area such as XSLT and rarely used image formats etc. Then only do the native versions for widely used features where it's worth the effort to maintain and vet them.

notherhack 1y ago

On my system I see that libxslt is a dependency for glib, gtk+, samba, systemd, pam, and a bunch of others. That's pretty foundational. What could possibly go wrong?

nwellnhof 1y ago
It's only a build dependency to generate documentation with DocBook stylesheets.