Created attachment 263364 [details] textproc/libxslt: fix a security issue Hi, here's the patch fixing a security issue in textproc/libxslt. Obtained from OpenBSD ports tree, here's the references: - https://cvsweb.openbsd.org/ports/textproc/libxslt/patches/?hideattic=1#dirlist - https://marc.info/?l=openbsd-ports-cvs&m=175654746526278&w=2 Thank you.
Neither have been merged upstream, and the second still does not have a CVE identifier assigned. Not really apt to commit these here until there is more appropriate upstream activity and testing, particularly with the new maintainer.
(In reply to Charlie Li from comment #1) Hi Charlie, thanks for the feedback. I do believe it's better to add some patches, following our review process (I'm ready to raise a review in phabricator), rather than keep the library (and dozens of dependencies) are vulnerable. Once we get a new release - we'll update the port and removal all unnecessary patches.
The port is scheduled for removal in 2 days: https://www.freshports.org/textproc/libxslt/ Is there a way to prevent this from happening?
(In reply to Christos Chatzaras from comment #3) Process is process, it must go finally. ¯\_(ツ)_/¯
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=85fe8f83037c1f1d815ad30e99dba29985909581 commit 85fe8f83037c1f1d815ad30e99dba29985909581 Author: Charlie Li <vishwin@FreeBSD.org> AuthorDate: 2025-09-11 18:48:14 +0000 Commit: Charlie Li <vishwin@FreeBSD.org> CommitDate: 2025-09-11 18:53:06 +0000 textproc/libxslt: remove deprecation notice and expire date There has been a new upstream maintainer since the deprecation notice was added. It will take some time for said new maintainer to get up to speed with the codebase and test any incoming patches. The software is still generally considered vulnerable as of this commit. PR: 289213 textproc/libxslt/Makefile | 3 --- 1 file changed, 3 deletions(-)
(In reply to Christos Chatzaras from comment #3) Prevented. (In reply to Sergey A. Osokin from comment #2) Our review process is no match to upstream's process. These patches have not been submitted as merge requests for upstream consideration, just the issues/bugs. The first issue even has multiple approaches, one of them includes an ABI break. As for clearing vulnerability notices/VuXML/etc, there are more security issues reported upstream that do not have fixes yet. In fact, there are (currently) no open merge requests dealing with reported security issues. Do not count on this getting any better anytime soon regardless of what we do (or not).
Hi, FYI: SUSE Linux Micro 6.0, AWS Linux 2 + 2023 & Oracle Linux 7-9 have now patched this issue. Redhat has acknowledged this issue last summer but no fix is currently available. What's the latest status for FreeBSD ? Thanks, a. External references: - https://www.suse.com/support/update/announcement/2025/suse-su-202520556-1/ - https://explore.alas.aws.amazon.com/CVE-2025-7424.html - https://linux.oracle.com/cve/CVE-2025-7425.html - https://securityvulnerability.io/vulnerability/CVE-2025-7424
(In reply to Arnaud de Prelle from comment #7) Thanks for sharing details, Arnaud. The current status is: the maintainer has provided a feedback, so the strategy is to waiting until libxslt project provides their patches to fix vulnerability or releases a new release that fixes all security issues.
(In reply to Sergey A. Osokin from comment #8) Seems a new release is out: https://github.com/GNOME/libxslt/releases/tag/v1.1.44
1.1.44 has not yet landed in the GNOME MASTER_SITES yet but hey at least it's tagged in the repository :-) Am taking a look but looks like it does not address every reported vulnerability. Looks like some fixes are still being evaluated upstream so they did not make it.
Now we have 1.1.45 upstream, which happened so it would populate in GNOME MASTER_SITES. No changes from 1.1.44. Unfortunately this will have to wait, since libxml2 >= 2.15.1 is now required.
fwiw, 1.1.45 https://github.com/diizzyy/ports-overlay/tree/19d6dd7f03932f130e2387339c5811e1a1045a61/textproc/libxslt Works for me (tm) including building various ports
(In reply to Daniel Engberg from comment #12) ...because cmake doesn't have the libxml2 version check that autotools has. For the umpteenth time, cmake will not be entertained in this port.
(In reply to Charlie Li from comment #13) Which I never claimed and it requires 2.15.1 which is what's being used in the overlay repo. Obstructing isn't productive or moving things forward and you can't delay things for months or even years especially when it fixes CVEs. Create a patch, do testing and request an exp-run to see what breaks.
Out of the vulnerabilities recorded in vuxml, only one is directly fixed in libxslt >= 1.1.44. Another, CVEed only because the reporter was using Debian or Ubuntu that shipped even older libxml2 and libxslt, was found to have been fixed in libxml2 since 2.9.10. Yet another is awaiting confirmation from libxslt maintainer that it is fixed in libxml2, backported to 2.14.6. Leaves one that is still open. Due to these disparate statuses, the vuxml entries that were bundled together will need redone. There is no point in creating a port patch and attempting to build it any further than the configure failure until libxml2 can be updated to at least 2.15.1.