libxml2: split to multiple versions, init libxml2_13, add patch for 5 CVEs

[gepbird]

This is a follow-up for #421204 and #421201, cc @alyssais

This solves the problem of not having a unified way to use the old libxml2 package. For some proprietary packages, it's not feasible to get a newer version of libxml2 working. One package used overrideAttrs, while another package vendored the old libxml2. I'll address these in separate PRs after this PR is accepted

This adds libxml2_13 package with a patch applied to fix the CVE

Unrelated to the aforementioned PRs, but I think it's safe to remove python2 support. I couldn't find any usages of it (I grepped for libxml2\. and libraries/libxml2)

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• Nixpkgs 25.11 Release Notes (or backporting 25.05 Nixpkgs Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
• NixOS 25.11 Release Notes (or backporting 25.05 NixOS Release notes)
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other contributing documentation in corresponding paths.

---

Add a 👍 reaction to pull requests you find important.

[alyssais]

Thank you so much for picking this up! Looks good to me at a glance, but I'll give the package maintainer a chance to comment. Want to also change all the packages currently overriding libxml2 to use this?

[emilazy]

Have any of the packages using the old version been tested with the new one, or is it just build errors from the changed soname? I know the ABI changed along with security fixes, but it seems it would be better to avoid the security issues and version proliferation if it ends up working in practice.

[gepbird]

Thank you so much for picking this up! Looks good to me at a glance, but I'll give the package maintainer a chance to comment. Want to also change all the packages currently overriding libxml2 to use this?

Thanks, but I want to address those packages in separate PRs. My reason is I'm planning to do other refactoring changes for those packages, and including those changes here would be too much for reviewers and probably delay getting this core change merged

[gepbird]

Have any of the packages using the old version been tested with the new one, or is it just build errors from the changed soname? I know the ABI changed along with security fixes, but it seems it would be better to avoid the security issues and version proliferation if it ends up working in practice.

@emilazy The example for the vendored (plex-desktop) was tested with the new libxml2, it didn't work: #418546 (comment)

I just tested the example for the overrideAttrs packages (ciscoPacketTracer8 and ciscoPacketTracer7) with the new libxml2, it suffers from the ABI breakage too:

nixpkgs ❯ ./result/bin/packettracer8        
/nix/store/qf1jkmmnwxc9y8wafxk41vr06gkplpsd-ciscoPacketTracer8-unwrapped/opt/pt/bin/PacketTracer: /nix/store/qf1jkmmnwxc9y8wafxk41vr06gkplpsd-ciscoPacketTracer8-unwrapped/lib/libxml2.so.2: no version information available (required by /nix/store/qf1jkmmnwxc9y8wafxk41vr06gkplpsd-ciscoPacketTracer8-unwrapped/opt/pt/bin/libQt5WebEngineCore.so.5)
/nix/store/qf1jkmmnwxc9y8wafxk41vr06gkplpsd-ciscoPacketTracer8-unwrapped/opt/pt/bin/PacketTracer: /nix/store/qf1jkmmnwxc9y8wafxk41vr06gkplpsd-ciscoPacketTracer8-unwrapped/lib/libxml2.so.2: no version information available (required by /nix/store/qf1jkmmnwxc9y8wafxk41vr06gkplpsd-ciscoPacketTracer8-unwrapped/opt/pt/bin/libQt5WebEngineCore.so.5)
/nix/store/qf1jkmmnwxc9y8wafxk41vr06gkplpsd-ciscoPacketTracer8-unwrapped/opt/pt/bin/PacketTracer: /nix/store/qf1jkmmnwxc9y8wafxk41vr06gkplpsd-ciscoPacketTracer8-unwrapped/lib/libxml2.so.2: no version information available (required by /nix/store/qf1jkmmnwxc9y8wafxk41vr06gkplpsd-ciscoPacketTracer8-unwrapped/opt/pt/bin/libQt5WebEngineCore.so.5)
/nix/store/qf1jkmmnwxc9y8wafxk41vr06gkplpsd-ciscoPacketTracer8-unwrapped/opt/pt/bin/PacketTracer: /nix/store/qf1jkmmnwxc9y8wafxk41vr06gkplpsd-ciscoPacketTracer8-unwrapped/lib/libxml2.so.2: no version information available (required by /nix/store/qf1jkmmnwxc9y8wafxk41vr06gkplpsd-ciscoPacketTracer8-unwrapped/opt/pt/bin/libQt5WebEngineCore.so.5)
/nix/store/qf1jkmmnwxc9y8wafxk41vr06gkplpsd-ciscoPacketTracer8-unwrapped/opt/pt/bin/PacketTracer: /nix/store/qf1jkmmnwxc9y8wafxk41vr06gkplpsd-ciscoPacketTracer8-unwrapped/lib/libxml2.so.2: no version information available (required by /nix/store/qf1jkmmnwxc9y8wafxk41vr06gkplpsd-ciscoPacketTracer8-unwrapped/opt/pt/bin/libQt5WebEngineCore.so.5)
/nix/store/qf1jkmmnwxc9y8wafxk41vr06gkplpsd-ciscoPacketTracer8-unwrapped/opt/pt/bin/PacketTracer: symbol lookup error: /nix/store/qf1jkmmnwxc9y8wafxk41vr06gkplpsd-ciscoPacketTracer8-unwrapped/opt/pt/bin/libQt5WebEngineCore.so.5: undefined symbol: valuePush, version LIBXML2_2.4.30

[emilazy]

Gotcha. Then this seems fine. I hope we can do undo it and don’t end up with five libxml2 versions, but that doesn’t seem practical right now.

[gepbird]

Are there any blockers? I feel like this has got enough reviews from enough people, including the package maintainer

Overall it is a refactor with python support removed and a new package, I feel like there's not much risk going forward with this as is

Note that there are packages on master with vulnerable, vendored libxml2 (2.13) libraries, which I'd love to start working on. However since the base of those future PRs could change at any time, I don't want to create extra work for myself

[LordGrimmauld]

I don't think there is any blockers, and i would merge if i could. Though this does need to go through staging, and staging people are aware of this PR. It'll likely be picked up for next cycle, though that cycle will have to wait ~2 weeks going by current schedule (current staging-next is running, 25.05 will be after that). Doesn't mean this can't be merged earlier though. In fact, i believe it should be merged soon, so the backport of the CVE fixes can be picked into the 25.05 cycle.