Created attachment 261105 [details] Patch for textproc/libxml2 I've created a patch to apply to "textproc/libxml2" that incorporates the fixes for CVE-2024-56171, CVE-2025-24928, and CVE-2025-32414, which I obtained from "https://github.com/GNOME/libxml2". Could you please review it?
Aloha freebsd-desktop team, can I support you in any way, to update libxml2 or to check, if these patches are fine? Best, tz (with ports-sec-hat)
Apply to quarterly as well, please.
(In reply to Torsten Zuehlsdorff from comment #1) yes, please!
(In reply to Max Brazhnikov from comment #3) > yes, please! How can i support you best?
Created attachment 261145 [details] libxml2.diff ^Triage: rebase patch.
As someone who has been trying to push a version that is supported upstream I'm not too fond of this idea. 2.11 branch is dead and unsupported upstream, there have been many changes to internal code between 2.11 - 2.14 so I would suggest that further investigation needs to be done to ensure that functionality is retained as intended and there are more CVEs but I didn't list all in VuXML. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libxml2 These are new and fixes have been committed upstream https://gitlab.gnome.org/GNOME/libxml2/-/issues/932 https://gitlab.gnome.org/GNOME/libxml2/-/issues/931 https://gitlab.gnome.org/GNOME/libxml2/-/issues/933 We do have a pretty much final version (PR 279705) however there are a few fallouts left. In case you're wondering about why there are two versions, the CMake version has been used for testing pretty much the whole time including fixing PRs except for the last exp-run (which is pretty much identical the previous one). The current also includes upstream commits (various bug fixes etc) which are to be included in next release for 2.14 branch which the other version lacks. Charlie is only one blocking it (so if you want to get it going I'd suggest you ask portmgr for a final decision, futher testing as it has recieved a lot less testing and evaluation) if we are go that route.
(In reply to Daniel Engberg from comment #6) I'm also not fond of this idea for the same and additional reasons. Not only have the internals changed, but starting 2.12, with a compatibility switch that has effectively gone away in 2.14, major (public) API changes happened. A member of portmgr chimed in over there saying we are going back to autotools. The only blockers anymore are fixing the remaining fallouts, and then the *autotools* version will be committed.