Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1241601

Bug#1102554: xmlrpc-c: bundles a (very old and) vulnerable copy of libexpat

Show all headers | View raw

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.

> Regards,
> Salvatore

cu
Adrian

Back to linux.debian.bugs.dist | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Bug#1102554: xmlrpc-c: bundles a (very old and) vulnerable copy of libexpat Salvatore Bonaccorso <carnil@debian.org> - 2025-04-10 13:10 +0200
  Bug#1102554: xmlrpc-c: bundles a (very old and) vulnerable copy of libexpat Adrian Bunk <bunk@debian.org> - 2025-04-12 11:40 +0200
    Bug#1102554: xmlrpc-c: bundles a (very old and) vulnerable copy of libexpat Alexandre Detiste <alexandre.detiste@gmail.com> - 2025-04-13 14:00 +0200
      Bug#1102554: xmlrpc-c: bundles a (very old and) vulnerable copy of libexpat Alexandre Detiste <alexandre.detiste@gmail.com> - 2025-04-14 08:40 +0200
  Bug#1102554: Outdated pkgconfig/xmlrpc.pc Richard Fuchs <dfx@dfx.at> - 2025-04-23 18:30 +0200
    Bug#1102554: Outdated pkgconfig/xmlrpc.pc Florian Ernst <florian@debian.org> - 2025-05-02 16:30 +0200
      Bug#1102554: Outdated pkgconfig/xmlrpc.pc Alexandre Detiste <alexandre.detiste@gmail.com> - 2025-05-02 17:10 +0200

csiph-web