Google has a program where you can submit patches to OSS projects (including libxslt) https://bughunters.google.com/about/rules/open-source/492808...

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)

Infrastructure-wise, XML digital signature implementations have to do transforms to convert the XML to the signed octet stream, and commonly use XSLT engines to do so. There was a fun early bug where one of the transforms that Xerces had was that you could include base64 encoded data, and it would load that as a java class against the transformer interface and execute it.

> Google refused to pay bounties for valid reports because I was a contributor to libxslt

Huh?

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."

https://hacks.mozilla.org/2010/06/beyond-html5-database-apis...

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

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.

Firefox uses TransforMiiX.

Historically, MSIE used MSXML and Opera used their own custom engine until they both moved to Blink which uses libxslt.

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.

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.

> we can't have SQLite because there's only 1 implementation

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

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.

While the Linux Foundation can provide some support, it's still up to each project to find their own maintainers (and pay for them).

They had a project called the Core Infrastructure Initiative that had similar goals, but it was abandoned long 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.

It's only a build dependency to generate documentation with DocBook stylesheets.

Yes, as it's a front-end to both LibXML2 and LibXSLT.

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.

In combination with https://docs.hyperclay.com/docs/docs-tldr-paste-in-llm/ it could be used to build a lightweight offline configuration editor, for instance.

XSLT are the "XSL Transformations".

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.

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.

> 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.

> 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.

> 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.

> Major browsers responded by deprecating/removing XSLT support

Its probably wrong to think the browser stuff is solely due to lack of maintainer.

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.