EPrints Technical Mailing List Archive

See the EPrints wiki for instructions on how to join this mailing list and related information.

Message: #10210

< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First

Re: [EP-tech] R: Libxml2 and FreeBSD

Hi Paolo,


I think that the way FreeBSD and Linux (in particular Long Term Support releases like RHEL, Debian, Ubuntu LTSs) do not change the version number of things like LibXML but apply a patch to the existing version.  So taking RHEL 10 for example the installed version is:


libxml2-2.12.5-7.el10_0.x86_64


This means version 2.12.5 but with 7 separate patches applied since its original release.  Taking some of the CVEs mentioned in your like (CVE-2025-49794, CVE-2025-49795, CVE-2025-49796 and CVE-2025-6021) these are all patched in the version of libxml2 shown above, as explained by:


https://access.redhat.com/errata/RHSA-2025:10630


Regarding 3.5.0-rc1 and 3.4.6, when it comes to core files, any security fixes to 3.4.x will also be applied to 3.5.x where applicable.  Although there are some quite big changes in 3.5.x, they are typically at a slightly higher level rather than low-level interaction with things like LibXML.  So my expectation would be that if 3.4.x has a low-level issue like this, so will 3.5.x.  We would look to review any changes made in 3.4.x and see if they need be applied to 3.5.x before its first full release.


Regards


David Newman



On 26/08/2025 15:47, Paolo Tealdi wrote:
CAUTION: This e-mail originated outside the University of Southampton.
Hi David.

Thank you for your quick answer.

I'm obviously aware of what means applying this patch. I DO NOT want that this patch would be applied. I provided this patch esclusively to explain quickly how to, apparently, resolve the problem (with that patch the command 'epadmin test [archive]'  doesn't coredump). 
If you haven't tested the latest libxml2 version, it is possible that the problem i referred is present also in a linux environment (and not only for FreeBSD env ). 
Unfortunately FreeBSD is very fast to update packages in its pkg environment (sometimes toomuch 🙂 ), above all when they are marked vulnerable: 2.12.5 is marked vulnerable https://www.vuxml.org/freebsd/abbc8912-5efa-11f0-ae84-99047d0a6bcc.html.

Some more informations:


I will do all the tests on 3.4.6, using both libxml2 versions and will submit an issue.

Best regards,
Paolo Tealdi


Ing. Paolo Tealdi                                                                                                                             ISIAD - Politecnico Torino            

Telefono/Phone : +39-011-0906714 , FAX : +39-011-0906625

Indirizzo/Address : C.so Duca degli Abruzzi,  24 - 10129 Torino - ITALY                     Skype : tealdi.paolo

Please consider your environmental responsibility before printing this e-mail


Da: David R Newman <drn@ecs.soton.ac.uk>
Inviato: martedì 26 agosto 2025 15:45
A: eprints-tech@ecs.soton.ac.uk <eprints-tech@ecs.soton.ac.uk>; Paolo Tealdi <paolo.tealdi@polito.it>
Oggetto: Re: [EP-tech] Libxml2 and FreeBSD
 

Hi Paolo,


Version 2.14.5 is the most recent version of LibXML2 (only released 15th July 2025), the latest version of have tested on is for RHEL 10, which is running LibXML 2.12.5 (patch version 7).


I am not overly happy as making a change to such a core file, as I am unsure what the side-effects may be.  I have quickly checked over the code base and I can only see once instance where the XML::LibXML::parse_file function which you propose changing in your diff has a second parameter for the basepath.  


This instance is in a command script (tools/phrases_map) rather than any code loaded by Apache.  I don't believe this script is needed, as it looks to be a legacy script for updating certain phrases between versions of EPrints.  I don't every remember using this script, so I reckon it is more than 10 years old, so I would probably just remove it, if I made a change to the parse_file function.  However, I am uncertain if any Bazaar plugins, ingredients, etc. may call this will a basepath.  I feel a better fix may be to only provide this second argument to XML::LibXML's parse_fh if it has a non-empty value.  E.g.


eval { $doc = $basepath ? $PARSER->parse_fh( $fh, $basepath ) : $PARSER->parse_fh( $fh ) };


Then if something does require the basepath then this does not suddenly break.  However, as I suspect is the case this basepath argument is barely ever used, then it will probably never affect your repository in the way you have described.


I think the best thing you can do is submit this as an issue on https://github.com/eprints/eprints3.4 as that is a better forum to discuss this in more detail.


Thanks and regards


David Newman


On 26/08/2025 14:13, Paolo Tealdi wrote:
CAUTION: This e-mail originated outside the University of Southampton.
CAUTION: This e-mail originated outside the University of Southampton.
Dear all,

more or less 1/2 month ago FreeBSD updated libxml2 its package from version 2.11.9   to version 2.14.5 and it's subsequent XML::LibXML perl package. 
With this upgrade eprints became very unstable, on our production server (3.3.15) and on our test server (3.4.6 and  3.5.0 beta 1). The instability seems to happen when it tries to read language files. For example with 3.5.0 the command 
#epadmin test [site] 
crashes with 'Bus Error' or ' Segmentation fault'
reading .../lib/lang/en/phrases/ep_template.xml

This error seems to disappear when applying this small patch

--- LibXML.pm   2025-08-26 15:02:20.844122000 +0200
+++ LibXML_new.pm       2025-08-26 15:02:46.564720000 +0200
@@ -130,7 +130,7 @@

        open(my $fh, "<", $file) or die "Error opening $file: $!";
        my $doc;
-       eval { $doc = $PARSER->parse_fh( $fh, $basepath ) };
+       eval { $doc = $PARSER->parse_fh( $fh ) };

modifying all the language xml files adding complete path on DTD definition.

Recompiling libxml2 from scratch (not using the package or ports) present the same instability.

The strange thing is that a very small program that reads the language files, without all the eprints infrastructure, works like a charme.

Anybody has found a similar problem ? Any ideas ? I can't test this problem on a Linux server for now, i fear that it is a eprints+FreeBSD related bug.

Best regards,
Paolo Tealdi


Ing. Paolo Tealdi                                                                                                                             ISIAD - Politecnico Torino            

Telefono/Phone : +39-011-0906714 , FAX : +39-011-0906625

Indirizzo/Address : C.so Duca degli Abruzzi,  24 - 10129 Torino - ITALY                     Skype : tealdi.paolo

Please consider your environmental responsibility before printing this e-mail