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 <[email protected]> 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.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)