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.
Companies have changed after seeing the log4j incident and are open to funding open source security (but we still need more)
Wowfunhappy 11 hours ago [-]
> Google refused to pay bounties for valid reports because I was a contributor to libxslt
Huh?
Cyykratahk 11 hours 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 10 hours 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.
layer8 9 hours ago [-]
People could fix each other’s intentionally introduced bugs and make a living that way.
The argument is less convincing when the bugs are a couple years old. There could be an exemption for that, but it’s also more work to verify (Git histories can be fabricated).
4 hours ago [-]
Wowfunhappy 9 hours ago [-]
They could anyway, one person intentionally introduced bugs and the other reports them. The reporter just avoids ever contributing code themself.
But doing any of this repeatedly without getting caught seems hard.
motorest 10 hours ago [-]
Not ridiculous. It's a clear conflict of interests, and represents a perverse incentive.
baq 9 hours 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.
motorest 8 hours 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.
I don't think that's how it works. I mean, how many problems did you ever fixed by dictating how others should spend their own money?
Also, apparently some of these issues exist for over a decade. That alone tells you how serious the problem is, and how urgent it needs fixing.
baq 6 hours ago [-]
I'm just saying they've got a bug bounty program but not a bug prevention bounty program, or even a fix a known bug bounty program. The security team has a budget for the realized risks but predictably not for managing unrealized risk in the open source community which they depend on.
x0x0 4 hours ago [-]
> a bug prevention bounty program
Particularly for a dep they've chosen to ship in their browser.
bryanrasmussen 11 hours ago [-]
it seems reasonable, if you report bugs in things you contribute to and this was allowed there would be a perverse incentive to inject bugs to have something to report on, furthermore if you are a contributor to a project that is the source of the bugs you have potentially an unfair advantage compared to every other potential reporter of bugs.
on edit: because obviously you probably become aware of bugs in your own projects before other people do.
alt187 9 hours ago [-]
As an end-user, I care very little about "unfair" advantages and a whole lot about actually solving bugs.
Plus, pushing intentionally buggy commits in a way that's subtle enough to be noticed, but not so subtle that it seems intentional (once the bug is revealed to be fixed) doesn't sound like the easiest way to make money. Especially on repeat. Wouldn't this be a little suspicious the third time around?
guappa 9 hours ago [-]
What's unreasonable is that they don't sponsor an important library they use.
whizzter 11 hours ago [-]
That this would even become a thing for established and widely depended on projects shows how broken our model currently is.
In cases like this though, if it involves code from before 2005-2010 the author shouldn't matter since people put very little thought into security back then.
justinclift 10 hours ago [-]
> an unfair advantage compared to every other potential reporter of bugs.
Where is the "unfair" in knowing about more bugs to get fixed?
"Fair" (or unfair) isn't a concept which is relevant to this.
tsimionescu 10 hours ago [-]
Unfairness is completely irrelevant here, there is 0 reason anyone would want a fair playing field for bug bounties, this isn't a competition. The other arguments do make sense, though.
bryanrasmussen 4 hours ago [-]
I see I need to clarify what I think about the unfairness aspect.
It is my experience that even much smaller companies than Google would have a Lawyer or multiple lawyers go over the details of how such a program would work.
The lawyers would of course talk to the developers and the project managers and interested parties and define risks. The risk of someone pushing in bugs to then report really seems like a programmer defined risk, but the unfairness thing is a lawyer defined risk. The first you conceive of thinking like a programmer, the second thinking like a lawyer.
But the risk I would assume a lawyer would see is - determining the severity of bugs is somewhat up to the developers and managers at our company, therefore we may encounter a situation in which a person reporting a bug thinks their bug is very severe but we think it is less severe, furthermore there may even be similar bugs in the past that we have paid out large amounts for but in this case we pay out a smaller amount, this will create an appearance of unfairness. The people pursuing the bug bounty have put in work to get the money, we of course will structure our contracts about bug bounty work etc. so that they cannot expect the process to be fair and that this is not a form of employment therefore the payout is not guaranteed, but that only goes so far, and if things look unfair then the shield our contracts offer may be blown apart.
The ability of someone to work on a project, and find bugs in that project quicker than other people gives them an advantage in reporting bugs therefore they need to invest less time to get a potential reward, they can report more bugs quicker etc.
Depending on jurisdiction, and we cover the damn world, this might be a problem because hey can someone who is not part of a project able to sue someone who is part of a problem somewhere because that person got more payoffs based on their access to the codebase of a project. Can our communications be requested to see if we evaluated things in any way unfairly?
What about if we have people on the same project as the guy that is reporting bugs for that project, can it be argued that we favor someone we "potentially" work with? This is another aspect of unfairness. Will they be able to sue and get access to communications regarding bug bounties in any case regarding unfairness - will our contract hold up against this?
For safety's sake let's just disallow these potential pieces of unfairness in the rules of the bug bounty, thus keeping from having any conflict of interest. Oh the developers said maybe someone could put in bugs in projects and then report it, seems legit also good reason we don't allow it. But yes, seems like a nasty can of worms all over, let's not open it.
The point of worrying about the unfairness is not that one thinks even that one would lose the case, but to avoid the case altogether, To have a contract that says essentially you can't do anything about it because we don't have to be fair, but then also remove anything that might look unfair.
> 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.
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?
joshkel 6 hours ago [-]
I assume you're referring to Web SQL? As I understand it, the argument against isn't just "there's only 1 implementation," it's "there's no standard and there's only 1 implementation," so the standard would have to devolve to "whatever that 1 implementation does."
From what I remember main argument was 'developer aesthetics', and then we got unusable without wrappers nonsensical IndexedDB.
x0x0 4 hours ago [-]
Ignoring, obviously, all parallels to chrome itself...
acdha 9 hours ago [-]
As others have pointed out there are multiple implementations of XSLT, but I’d also argue that this situation seems like a decent argument in favor of that policy. If everyone is using a single implementation then in practice that implementation is the standard and things like Hyrum’s law become serious considerations.
XSLT is grandfathered in from the early days of the web, and while it’s turned out better than Microsoft exposing random COM interfaces which even Windows developers hated it’s still something of a cautionary example of a feature which never really caught on but browser developers have to support decades later or be willing to break a modest number of sites, some relatively important in particular niches like government information. I think of what happened with WebSQL as a reaction to the maintenance costs of a decade earlier.
foul 12 hours 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]
Isn't the situation essentially the opposite? We apparently can't have it in the standard just because Google don't want to maintain the specific implementation they have chosen for their browser.
simonw 13 hours ago [-]
Firefox uses TransforMiiX.
Historically, MSIE used MSXML and Opera used their own custom engine until they both moved to Blink which uses libxslt.
tannhaeuser 12 hours 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.
rleigh 4 hours ago [-]
And also in QtXmlPatterns (now also retired).
Just for the record, Xalan-C is even less maintained than libxslt. It had no releases for over a decade, and I made a final 1.12 release in 2020 adding CMake support, since the existing builds had bitrotted significantly, along with a number of outstanding bugfixes.
It's a great shame we are now in a situation where there is only a single proprietary implementation of the very latest version of the standard, but even the open-source 1.x implementations are fading fast. These technologies have fallen out of favour, and the the size and complexity of the standards is such that it's a non-trivial undertaking to keep them maintained or create a modern reimplementation.
> 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.
Not my experience, they all have different ideas of what the current node is at any one point in the execution of a script.
mardifoufs 8 hours ago [-]
Wait, so what's the reason for the W3C going against its own policy? Is it okay since it's just a recommendation?
gwd 10 hours ago [-]
> we can't have SQLite because there's only 1 implementation
Well now there are [1] at least [2] three [3] implementations, right?
We actually have three distinct one-of-one libraries.
There's no standard, so there's no way to really evaluate how standards-compliant they are.
It seems like the idea is for the turoso projects to be compatible with sqlite, but it's not clear exactly what means.
As a fork, libsql could be kept reasonably backward compatible with recent versions of sqlite by keeping up with merging changes, and avoiding extending sql in conflicting ways. That seems doable if they keep up with the merges, though mainly because they share very large parts of the implementation, so it's not clear it counts as a separate implementation from a web standards perspective.
Turso seems like a reimplementation and has a while to go before it achieves some level of compatibility. It probably needs to be much further along before we can really even evaluate it.
bryanrasmussen 13 hours 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.
grandinj 12 hours 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?
the_biot 8 hours ago [-]
They had a project called the Core Infrastructure Initiative that had similar goals, but it was abandoned long ago.
arccy 10 hours 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 10 hours ago [-]
That is a pity. Clearly we need some kind of
Home For Abandoned Code
:-)
jve 8 hours 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.
there exist at least one or two of those. i can't think of the name unfortunately. i believe it has been discussed on hackernews too.
https://www.commonhaus.org/ seems to be something similar, but that's not what i was thinking of. the one i remember focused on projects that their maintainers wanted to give up right away.
arp242 6 hours ago [-]
If no one cares enough to do some basic maintenance then maybe it should die?
tempfile 11 hours 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.
notherhack 5 hours 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 5 hours ago [-]
It's only a build dependency to generate documentation with DocBook stylesheets.
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.
burnt-resistor 17 hours 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
> 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.
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.
bkor 14 hours 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.
chrismorgan 12 hours 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 9 hours 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.
bawolff 14 hours 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 13 hours ago [-]
Not directly, but if the most used implementation is unmaintained how popular is the language?
bawolff 10 hours 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 7 hours 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.
sitharus 13 hours 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.
mjw1007 12 hours 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.
MangoToupe 15 hours ago [-]
[flagged]
alexjplant 15 hours 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 11 hours ago [-]
Ok, but my question stands. What value does this provide society?
jamesnorden 10 hours ago [-]
What value do you provide society?
MangoToupe 8 hours ago [-]
How is this relevant to figuring out why xml document transformations exist?
I feed my family.
alexjplant 7 hours ago [-]
Stop posting on HN and go read "Ishmael" if this is how you feel. 100% serious, no snark.
> XSLT ... is a language for transforming XML documents into other XML documents. ... XSLT is designed for use as part of XSL, which is a stylesheet language for XML.
If you don't know what "XML" is, go ask your favorite search engine.
If you want to know who uses XSLT, go review the existing discussion on the topic. In summary, it's a bunch of people that Google doesn't really care about (and almost certainly far more people than use WebUSB or WebMIDI [1] and the like).
My question stands. What value does this provide society?
therein 15 hours 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.
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.
The patches need to fix a systemtic design flaw (which seems like you are trying to do).
You are eligible even if you are a contributor:
> Q: I'm a core developer working on one of the in-scope projects. Do my own patches qualify?
> A: They most certainly do.
Additionally, github has: https://resources.github.com/github-secure-open-source-fund/
Companies have changed after seeing the log4j incident and are open to funding open source security (but we still need more)
Huh?
The argument is less convincing when the bugs are a couple years old. There could be an exemption for that, but it’s also more work to verify (Git histories can be fabricated).
But doing any of this repeatedly without getting caught seems hard.
I don't think that's how it works. I mean, how many problems did you ever fixed by dictating how others should spend their own money?
Also, apparently some of these issues exist for over a decade. That alone tells you how serious the problem is, and how urgent it needs fixing.
Particularly for a dep they've chosen to ship in their browser.
on edit: because obviously you probably become aware of bugs in your own projects before other people do.
Plus, pushing intentionally buggy commits in a way that's subtle enough to be noticed, but not so subtle that it seems intentional (once the bug is revealed to be fixed) doesn't sound like the easiest way to make money. Especially on repeat. Wouldn't this be a little suspicious the third time around?
In cases like this though, if it involves code from before 2005-2010 the author shouldn't matter since people put very little thought into security back then.
Where is the "unfair" in knowing about more bugs to get fixed?
"Fair" (or unfair) isn't a concept which is relevant to this.
It is my experience that even much smaller companies than Google would have a Lawyer or multiple lawyers go over the details of how such a program would work.
The lawyers would of course talk to the developers and the project managers and interested parties and define risks. The risk of someone pushing in bugs to then report really seems like a programmer defined risk, but the unfairness thing is a lawyer defined risk. The first you conceive of thinking like a programmer, the second thinking like a lawyer.
But the risk I would assume a lawyer would see is - determining the severity of bugs is somewhat up to the developers and managers at our company, therefore we may encounter a situation in which a person reporting a bug thinks their bug is very severe but we think it is less severe, furthermore there may even be similar bugs in the past that we have paid out large amounts for but in this case we pay out a smaller amount, this will create an appearance of unfairness. The people pursuing the bug bounty have put in work to get the money, we of course will structure our contracts about bug bounty work etc. so that they cannot expect the process to be fair and that this is not a form of employment therefore the payout is not guaranteed, but that only goes so far, and if things look unfair then the shield our contracts offer may be blown apart.
The ability of someone to work on a project, and find bugs in that project quicker than other people gives them an advantage in reporting bugs therefore they need to invest less time to get a potential reward, they can report more bugs quicker etc.
Depending on jurisdiction, and we cover the damn world, this might be a problem because hey can someone who is not part of a project able to sue someone who is part of a problem somewhere because that person got more payoffs based on their access to the codebase of a project. Can our communications be requested to see if we evaluated things in any way unfairly?
What about if we have people on the same project as the guy that is reporting bugs for that project, can it be argued that we favor someone we "potentially" work with? This is another aspect of unfairness. Will they be able to sue and get access to communications regarding bug bounties in any case regarding unfairness - will our contract hold up against this?
For safety's sake let's just disallow these potential pieces of unfairness in the rules of the bug bounty, thus keeping from having any conflict of interest. Oh the developers said maybe someone could put in bugs in projects and then report it, seems legit also good reason we don't allow it. But yes, seems like a nasty can of worms all over, let's not open it.
The point of worrying about the unfairness is not that one thinks even that one would lose the case, but to avoid the case altogether, To have a contract that says essentially you can't do anything about it because we don't have to be fair, but then also remove anything that might look unfair.
"Remove mentions of XSLT from the html spec" (9 days ago, 388p, 534c) 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
"Should the web platform adopt XSLT 3.0?" (6 days ago, 133p, 107c) 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
> 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.youtube.com/watch?v=U1kc7fcF5Ao
https://hacks.mozilla.org/2010/06/beyond-html5-database-apis...
XSLT is grandfathered in from the early days of the web, and while it’s turned out better than Microsoft exposing random COM interfaces which even Windows developers hated it’s still something of a cautionary example of a feature which never really caught on but browser developers have to support decades later or be willing to break a modest number of sites, some relatively important in particular niches like government information. I think of what happened with WebSQL as a reaction to the maintenance costs of a decade earlier.
[0] https://www.saxonica.com/saxon-c/index.xml
Historically, MSIE used MSXML and Opera used their own custom engine until they both moved to Blink which uses libxslt.
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.
Just for the record, Xalan-C is even less maintained than libxslt. It had no releases for over a decade, and I made a final 1.12 release in 2020 adding CMake support, since the existing builds had bitrotted significantly, along with a number of outstanding bugfixes.
I initiated its removal to the Apache attic in 2022 in https://marc.info/?l=xalan-c-users&m=165593638018553&w=2 and the vote to do this was in https://marc.info/?t=166514497300001&r=1&w=2&n=20. It has now gone nearly four years without any commits being made.
It's a great shame we are now in a situation where there is only a single proprietary implementation of the very latest version of the standard, but even the open-source 1.x implementations are fading fast. These technologies have fallen out of favour, and the the size and complexity of the standards is such that it's a non-trivial undertaking to keep them maintained or create a modern reimplementation.
https://gitlab.gnome.org/balls/xrust
https://gitlab.gnome.org/vandenoever/xust/
Not my experience, they all have different ideas of what the current node is at any one point in the execution of a script.
Well now there are [1] at least [2] three [3] implementations, right?
[1] sqlite.org
[2] https://github.com/tursodatabase/libsql
[3] https://github.com/tursodatabase/turso
There's no standard, so there's no way to really evaluate how standards-compliant they are.
It seems like the idea is for the turoso projects to be compatible with sqlite, but it's not clear exactly what means.
As a fork, libsql could be kept reasonably backward compatible with recent versions of sqlite by keeping up with merging changes, and avoiding extending sql in conflicting ways. That seems doable if they keep up with the merges, though mainly because they share very large parts of the implementation, so it's not clear it counts as a separate implementation from a web standards perspective.
Turso seems like a reimplementation and has a while to go before it achieves some level of compatibility. It probably needs to be much further along before we can really even evaluate it.
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.
Taking ownership of unmaintained projects so that at least they have the bare minimum of patches being applied, CI/CD running, releases being created?
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.
I kid. Mostly.
https://www.commonhaus.org/ seems to be something similar, but that's not what i was thinking of. the one i remember focused on projects that their maintainers wanted to give up right away.
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.
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
--- List
0: https://gitlab.gnome.org/GNOME/libxslt/-/issues/139
1: https://gitlab.gnome.org/GNOME/libxslt/-/issues/140
2: https://gitlab.gnome.org/GNOME/libxslt/-/issues/144
3: https://gitlab.gnome.org/GNOME/libxslt/-/issues/148
4: BIGSLEEP-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_245...
List of FreeBSD ports that are unlikely to build without `make DISABLE_VULNERABILITIES=yes`:
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.
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.
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.
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.
Its probably wrong to think the browser stuff is solely due to lack of maintainer.
There are definitely still users, although a lot of them are probably outside the browser.
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.
It’s not (and never was outside of corporate webapps) very common on the web, but there are still legacy things that need it.
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.
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.
I feed my family.
As described in [0]
> XSLT ... is a language for transforming XML documents into other XML documents. ... XSLT is designed for use as part of XSL, which is a stylesheet language for XML.
If you don't know what "XML" is, go ask your favorite search engine.
If you want to know who uses XSLT, go review the existing discussion on the topic. In summary, it's a bunch of people that Google doesn't really care about (and almost certainly far more people than use WebUSB or WebMIDI [1] and the like).
[0] <https://www.w3.org/TR/1999/PR-xslt-19991008>
[1] Yes, really.