On Sat, Jul 05, 2025 at 10:35:27AM +0200, Sylvain Beucler wrote: > Hi, Hi Sylvain,
> Are there current plans for bookworm to patch the old expat embedded copy in > xmlrpc-c? > > This can probably be done along with fixing libxmltok, which is a similarly > old version of expat. > > For LTS, following a review of pending work from the LTS Coordinators, we're > considering whether to initiate such work for bullseye. > > Salvatore, Adrian, what do you think? :) Thorsten did a lot of work on libxmltok in April and May,[1,2] it would be useful if he could update the security tracker with the results and then finish his work on the fixes for the CVEs that do affect libxmltok. The expat code in xmlrpc-c differs from the code in libxmltok even though they are both expat 1.2 due to xmlrpc-c having done code changes in their fork, but getting the fixes from libxmltok there shouldn't be a huge extra effort. libxmltok has zero code changes between the upload of 1.2-1 21 years ago and bookworm, and the upstream changes to the fork in xmlrpc-c also seem to be old with no code differences between stretch and bookworm. This implies that fixing one distribution should get us fixes for all distributions from stretch to bookworm. > Cheers! > Sylvain Beucler > Debian LTS Team cu Adrian [1] http://blog.alteholz.eu/2025/05/my-debian-activities-in-april-2025/ [2] http://blog.alteholz.eu/2025/06/my-debian-activities-in-may-2025/ > On Sat, 12 Apr 2025 12:36:04 +0300 Adrian Bunk <b...@debian.org> wrote: > > On Thu, Apr 10, 2025 at 12:57:14PM +0200, Salvatore Bonaccorso wrote: > > >... > > > Triggered by the oss-security post from the expat upstream maintainer: > > > https://www.openwall.com/lists/oss-security/2025/04/09/4 > > > > It might be worth to use similar patch to make xmlrpc-c switch to > > use > > > the system expat instead of the internal copy. > > > > Ideally usptream would even just remove the upstream embedded source > > > but from what I read in the above there is no interest in that for > > > now. > > > > https://raw.githubusercontent.com/gentoo/gentoo/61b6130343a41b49da1ffe7376ab5d2077a37411/dev-libs/xmlrpc-c/files/xmlrpc-c-1.59.03-use-system-expat.patch > > > is the patch by Sebastian Pipping to use the system libexpat. > > >... > > > > The options offered by upstream are internal expat or external libxml2, > > and external libxml2 is the new upstream default. > > > > Building the package with external libxml2 worked for me. > > > > No matter whether we use the supported external libxml2 or patch in > > support for external expat, this means xmlrpc-c will drop the two > > libraries containing the vendered expat from libxmlrpc-core-c3t64 > > (libxmlrpc_xmlparse.so and libxmlrpc_xmltok.so). > > > > For trixie an option might be: > > - switch to external libxml2 > > - for a new library name compared to bookworm, > > dropping the ${t64:Provides} would be an option > > > > There does not seem to be any other package actually linking to any of > > the two libraries containing the vendored expat, but 3rd party software > > might do so in *stable. > > In bookworm: > > $ xmlrpc-c-config --libs -L/usr/lib/x86_64-linux-gnu -lxmlrpc > > -lxmlrpc_xmlparse -lxmlrpc_xmltok -lxmlrpc_util > > $ > > as-needed obviously helps and headers don't seem to be installed, but > > these libraries should perhaps be provided as stubs if they disappear > > in *stable. > > > > Another issue for *stable is that changing the XML parser might result > > in behaviour changes. > > > > Relevant for *stable would also be whether that would actually reduce > > the number of expat1 copies that need fixing to zero. > > > > src:libxmltok is expat1 with a different name. > > CVE-2021-46143 was fixed in trixie, other expat CVEs need triaging. > > php8.4 has a (stale?) build dependency on libxmltok1-dev.
