RFE: switch away from xmlSetExternalEntityLoader
Bug #2125513 reported by
Cole Robinson
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| lxml |
Confirmed
|
Medium
|
scoder | ||
Bug Description
Valid with lxml git as of Sep 22 2025
lxml uses xmlSetExternalE
libxml2 2.14.0 (released Mar 2025) added xmlCtxtSetResou
It would be nice if lxml could switch to that, when timing is appropriate. It would require bumping the minimum libxml2 version.
Thank you!
To post a comment you must log in.

To expand a bit: virt-install/ virt-manager does a lot of XML processing with libxml2 python bindings. we also talk to libvirt which uses libxml2 from C. libxml2 python bindings are going away, and we would like to move virt-install to use lxml. but any global callback stuff makes me wary. and lxml docs still explicitly warn against mixing with other libxml2 users unless lxml is built statically, which it isn't in Red Hat distro packages.
In the past, pre lxml 2020 commit that fixed https:/ /bugs.launchpad .net/lxml/ +bug/1880251 , just `import lxml` followed by calling into libvirt would crash immediately. the current state of lxml is way better, but still doesn't look safe in all our usage scenarios. virt-install/ virt-manager does invoke some libvirt calls in threads, and the callback set by xmlSetExternalE ntityLoader is not thread local, so it's still possible libvirt could end up calling into lxml code, with unexpected results.
I know there's been a ton of churn and API deprecations in libxml2 lately, but I think they added APIs that make all the global config stuff obsolete. hopefully lxml can get to a place that it's safe to mix with other libxml2 inprocess users, provided they are well-behaving (which libvirt is). especially with the libxml2 python bindings potentially going away