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.
burnt-resistor•1h ago
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.