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

Groups > linux.debian.bugs.dist > #1241293 > unrolled thread

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

Back to article view | Back to linux.debian.bugs.dist

Contents

  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

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

Source: xmlrpc-c
Version: 1.59.03-7
Severity: important
Tags: upstream security
X-Debbugs-Cc: carnil@debian.org,team@security.debian.org

Hi

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.

Regards,
Salvatore

[toc] | [next] | [standalone]

#1241601

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

[toc] | [prev] | [next] | [standalone]

#1241785

Hi,

First of all I'm 100% open with co-maintenance of xmlrpc-c.

I think that libxmltok should be removed if it is a less well
maintained copy of libxml2-dev
without any user.

php8.4 build-depends on both but maybe it does not need libxmltok1t64 at all;
-> there's no runtime dependency generated.

$ reverse-depends libxmltok1t64
Reverse-Depends
===============
* libxmltok1-dev

$ reverse-depends -b libxmltok1-dev
Reverse-Build-Depends
=====================
* php8.4


I would consider these XML lib as private implementation details
and do not plan to create stub libraries for non-existing usage.

I'll handle the switch to external libxml2 soon.

Greetings

Le sam. 12 avr. 2025 à 11:39, Adrian Bunk <bunk@debian.org> a écrit :
>
> 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

[toc] | [prev] | [next] | [standalone]

#1241922

PS: I reopened the old php bug.

The same old patch still apply => remove 1 line from debian/control{.in}

$ bts tag 691755 -wontfix
$ bts unarchive 871826
$ bts reassign 871826 src:php8.4
$ bts retitle 871826 php8.4: Please remove unused libxmltok1-dev from
Build-Depends
$ bts reopen 871826
$ bts severity 871826 important

> > 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

[toc] | [prev] | [next] | [standalone]

#1243337 — Bug#1102554: Outdated pkgconfig/xmlrpc.pc

Hi,

The packages pkgconfig/xmlrpc.pc file still refers to xmlrpc_expat which 
now doesn't exist any more, so building anything against xmlrpc-c fails.

$ pkg-config xmlrpc --libs
Package xmlrpc_expat was not found in the pkg-config search path.
Perhaps you should add the directory containing `xmlrpc_expat.pc'
to the PKG_CONFIG_PATH environment variable
Package 'xmlrpc_expat', required by 'xmlrpc', not found

Thanks

[toc] | [prev] | [next] | [standalone]

#1244473 — Bug#1102554: Outdated pkgconfig/xmlrpc.pc

[Multipart message — attachments visible in raw view] — view raw

On Wed, Apr 23, 2025 at 12:24:40PM -0400, Richard Fuchs wrote:
> The packages pkgconfig/xmlrpc.pc file still refers to xmlrpc_expat which now
> doesn't exist any more, so building anything against xmlrpc-c fails.

Furthermore xmlrpc-c-config still references the dropped libraries
(libxmlrpc_xmlparse.so and libxmlrpc_xmltok.so), so rtorrent FTBFS now,
cf. <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1104366>.

| $ xmlrpc-c-config server-util --libs
| -L/usr/lib/x86_64-linux-gnu   -lxmlrpc_server -lxmlrpc  -lxmlrpc_xmlparse -lxmlrpc_xmltok -lxmlrpc_util -lpthread

HTH,
Flo

[toc] | [prev] | [next] | [standalone]

#1244477 — Bug#1102554: Outdated pkgconfig/xmlrpc.pc

Thank you for the heads up.

I never received Richard's email from Wed, 23 Apr 2025 12:24:40 -0400

Greetings

Le ven. 2 mai 2025 à 16:22, Florian Ernst <florian@debian.org> a écrit :
>
> On Wed, Apr 23, 2025 at 12:24:40PM -0400, Richard Fuchs wrote:
> > The packages pkgconfig/xmlrpc.pc file still refers to xmlrpc_expat which now
> > doesn't exist any more, so building anything against xmlrpc-c fails.
>
> Furthermore xmlrpc-c-config still references the dropped libraries
> (libxmlrpc_xmlparse.so and libxmlrpc_xmltok.so), so rtorrent FTBFS now,
> cf. <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1104366>.
>
> | $ xmlrpc-c-config server-util --libs
> | -L/usr/lib/x86_64-linux-gnu   -lxmlrpc_server -lxmlrpc  -lxmlrpc_xmlparse -lxmlrpc_xmltok -lxmlrpc_util -lpthread
>
> HTH,
> Flo

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web