[Bug 288864] textproc/libxslt: when will the situation with libxslt-1.1.43 be fixed?

From: <bugzilla-noreply_at_freebsd.org>
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.