So, to clarify my plans regarding libxml2:

• libxml2 is seeing a lot of CVEs recently. It requires a lot of maintenance to stay secure.
• As it stands, we do not have anyone particularly invested in libxml2, I am doing my best to pick up the slack.
• The upstream maintainer announced they would stop maintaining libxml2 upstream by the end of 2025
• The libxslt upstream maintainer offered to take over libxml2 maintenance
  • they might not backport security patches to all existing old versions (2.13 got an upstream backport just this week, but this seems not guaranteed)
  • we could piggy-back of gentoo and fetch their patches into our libxml2. I would reserve this as a backup plan, in case we have to back out of the 2.15 update. The other distros are all either on 2.15 already (arch), or on ancient versions they keep patching along.
  • i would personally prefer only supporting the latest (=2.15.x) version for 25.11, which makes this PR important to land before staging feature freeze (2025-10-04)
• 2.15 API changes are there and do cause breakage, but might be easier to resolve than the 2.13 -> 2.14 bump.
• If i can help it, i do not want to get stuck back-porting CVE fixes again (as @gepbird and I did for 25.05 to some degree)

cc @vcunat who chimed in about libxml2 things in the staging matrix chat
cc @jopejoe1 @leona-ya for release manager things - you want me to cross-post this in #444721 ?

Thanks for the reminder, I see there are 2 new CVEs that probably need backporting to libxml2_13, I'll check it out this week. I don't mind maintaining it during the upcoming 25.11 release, but I understand at most only tens of packages use it, and most of them (if not all) can use a vulnerable vedored libxml2 library.

I'll leave the libxml >=2.14 up to you, I don't have capacity to take new bigger responsibilities in the near future.

I see there are 2 new CVEs that probably need backporting to libxml2_13

There is a 2.13.9 release which fixes most (if not all) of the CVEs, maybe you don't need manual backports this time

Things tested:

• libxml2
• libxslt
• python3Packages.lxml
• xmlsec
• librsvg
• perlPackages.XMLLibXML (includes some other perl xml deps)
• xmlstarlet
• dvdauthor
• python3Packages.beautifulsoup4
• ldc

This is basically all of the things that complained in the libxml2 2.13 -> 2.14 transition. I am reasonably confident this is not going to explode completely, even if merged now.

However, librsvg having a failing test because of the maximum element count is still concerning. I'll need to verify this is not a security-critical regression in libxml2. After that, this should be fine to merge.

librsvg test fails reported upstream, time to wait for what they say.
https://gitlab.gnome.org/GNOME/librsvg/-/issues/1201

Okay, i have dug through libxml2 and librsvg, and conclude: the too_many_elements fail is just a case of a different error being thrown, this is not a security-critical regression.

As mentioned by @wolfgangwalther, there's a regression in 2.15.0 (affecting PostgreSQL) which is described here: https://www.postgresql.org/message-id/flat/0756AC61-FBA3-46E2-B3C2-19B58B65EBDC%40yesql.se#9dcf38aa46f38a215648f75bd471567b

Both upstreams already have unreleased fixes:

• https://gitlab.gnome.org/GNOME/libxml2/-/commit/da45a190f718e8e2f0e3d2a6325ffa23abc8b90c
• postgres/postgres@a48d1ef

affecting PostgreSQL

Their patch has already been applied for us in #448817

So the libxml2 patch isn't urgent anymore?

We should still do the patch - from experience, there is a LOT of things that will run into random build failures due to libxml2 changes, postgres isprobably not the only one