Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XML::LibXML 2.0201+ requires enabling of External DTDs #511

Open
drn05r opened this issue Jan 30, 2020 · 5 comments
Open

XML::LibXML 2.0201+ requires enabling of External DTDs #511

drn05r opened this issue Jan 30, 2020 · 5 comments
Labels
Milestone

Comments

@drn05r
Copy link
Contributor

@drn05r drn05r commented Jan 30, 2020

Reported by Paolo Tealdi via Eprints-tech

this version the module needs one more MANDATORY option at startup, that enables
external DTD parsing, now disabled by default.

@drn05r drn05r added the bug label Jan 30, 2020
@drn05r drn05r added this to the 3.3.17 milestone Jan 30, 2020
@jesusbagpuss
Copy link
Contributor

@jesusbagpuss jesusbagpuss commented Apr 7, 2020

Just adding this note - gathering the info in one place.

From EP-Tech:

--- XML/LibXML_old.pm 2017-04-28 11:03:16.000000000 +0200
+++ XML/LibXML.pm     2020-01-30 08:42:55.273103000 +0100
@ AT  -66,7 +66,7 @ AT 

 ##############################################################################

-our $PARSER = XML::LibXML->new();
+our $PARSER = XML::LibXML->new( expand_entities=>1, load_external_dtd=>1);

 sub CLONE
 {

@jesusbagpuss
Copy link
Contributor

@jesusbagpuss jesusbagpuss commented Apr 7, 2020

Other places that might need to be addressed:

sub CLONE
{
$PARSER = XML::LibXML->new();
}

my $source = XML::LibXML->new->parse_fh( $fh );

@denics
Copy link
Contributor

@denics denics commented Apr 7, 2020

Hi guys, as this is of actuality again :) I was wondering few years ago, why EPrints is including these libraries as part of the code and it is not using a dependency system

@jesusbagpuss
Copy link
Contributor

@jesusbagpuss jesusbagpuss commented Apr 7, 2020

@denics it might be because, inolder versions, EPrints supported other XML libraries (GDOME, DOM), and the EPrints::XML::zzz modules were to create a more standard way to interface to all of them?
(but that was all a long time ago - and I might be wrong!)

I'd hope that somewhere in the 3.4 series, there will be a review of the code base, and refactor on a standard library (LibXML seems to be the winner!?).

@denics
Copy link
Contributor

@denics denics commented Apr 7, 2020

Yep, indeed you are right, but now we should be able to get rid of all of them. I do not remember where I did propose some patches, I do not think in here, maybe in the eprintsug group. I remember that I did that because exactly libXML that had a major critical bug and EP was still using the old one. It is not a big job to rely on system libs now Perl using carton or even cpanm.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants