3 ms·
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
by 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 agoNot directly, but if the most used implementation is unmaintained how popular is the language?
- sitharus 1y agoThese 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 agoIts 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 agoI 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 agoIt'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.