[Bug 288864] textproc/libxslt: when will the situation with libxslt-1.1.43 be fixed?
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 19 Aug 2025 20:33:31 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288864 --- Comment #5 from Matthias Andree <mandree@FreeBSD.org> --- (In reply to Gleb Popov from comment #3) Note: Whether a package A (say, libxslt) is a build-time dependency or run-time dependency for your application package B ** does not in any way ** state or say anything about whether the software B using vulnerable package A is vulnerable. If it is, depends on how the software A is used by B, and if package A ships, for instance, static libraries (often .a), object files (.o or maybe .obj), or a source code library (in whatever programming language), all three are obvious ways that B can incorporate code from A, besides the commonplace shared object or shared library (.so, Windows would call those .dll). Also, if packages are binary or source does not in any way by itself say anything about vulnerability. libxslt provides both static (.a) and shared libraries (.so). Vulnerable *static* (.a, .o, source code including header-only libraries in some programming languages) libraries that end up in other software are more effort to fix overall because you can't swap out the vulnerable library by a bugfixed version later, but you must re-link the software in question, maybe also recompile it. For shared libraries where bugfixes for vulnerabilities are made in a ABI compatible manner, it suffices to reinstall a bugfixed version of the .so library and to restart the application that used the vulnerable version. As to when will it be fixed? That depends on the new maintainer who volunteered and needs to get acquainted with the code, review extant bug and vulnerability reports, fix them, ideally gets them reviewed by experts, and manages to make a new release. Getting acquainted with somebody else's codebase takes its time. ----- (In reply to from Andre Rikkert de Koe from comment #2) Feel free to propose a better wording and offer a patch for VuXML if you care. I'm not sure if it's worth chasing phantoms and adding more "there's a bug but we don't know what". Not all details of newly reported vulnerabilites had been disclosed when I wrote the original VuXML entry for libxslt, and since then, new vulnerabilities with disclosure two months from new were added to the table in https://gitlab.gnome.org/Teams/Releng/security/-/wikis/2025#libxml2-and-libxslt - if you click through the links, two lead to "404" pages. That's because the issues exist but are non-public. Gitlab has the habit of pretending non-existence of the things that we or you are not allowed to see. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.