hi Rob!
What would be the best/cleanest fix for this issue? It affects quite a lot of apps
out there.
Thanks!

[2013-05-29 07:20 UTC] Sjon at hortensius dot net

I can confirm this issue; it is very annoying and unexpected. Can't the code, as
a work-around use file-get-contents + simplexml_load_string internally?
This issue is also related to #22215 imo

[2013-05-29 07:21 UTC] sjon at hortensius dot net

I can confirm this issue; it is very annoying and unexpected. Can't the code, as
a work-around use file-get-contents + simplexml_load_string internally?
This issue is also related to bug #64938 imo

[2013-08-29 07:18 UTC] ivan dot enderlin at hoa-project dot net

ping? Any news from the front?

[2013-12-15 01:19 UTC] claudio dot mulas at lucla dot net

Finally i've found what's the problem on my website. Still not fixed? :(

[2014-01-27 16:44 UTC] phofstetter at sensational dot ch

External entity loading in XML is problematic security-wise (see https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing and for example http://www.ubercomp.com/posts/2014-01-16_facebook_remote_code_execution where Facebook was hit by that).
It's generally advised to turn off external entity loading.
But because of this bug, turning that off also turns off *all* external file loading via libxml.
What we need IMHO is something that turns off loading files in response to parsing untrusted XML. Requesting XML from an external source in itself isn't a problem.
If this current behaviour is intended, please consider adding a note to the documentation explaining the case and telling users to use fopen (though that means that it's no longer possible to work with a huge stream of XML data because libxml_disable_entity_loader() also disables XmlReader::open()

[2014-01-29 13:03 UTC] phofstetter at sensational dot ch

This bug causes libxml_disable_entity_loader(true); to also disable SoapClient - likely for the same reason. Contrary to the other options, this one is bad though because there's no workaround (asides of not using PHP's own SoapClient).
So as it stands now users either have to live with an annoying security hole when parsing untrusted XML (which does happen at times) or with a defunct SOAP client plus the nice fopen wrappers not working for all XML related functions.

I don't see how this is a bug, the function is called "simplexml_load_file", so the expected behavior is that it will load content of a file, and if you don't give valid path, you get an error and false.
It is also documented like that, so please just close this, changing this behavior will probably brake a lot of applications also.

[2018-05-22 11:12 UTC] phofstetter at sensational dot ch

> and if you don't give valid path, you get an error and false.
of course. But this bug is about `simplexml_load_file` failing on *any* valid path if `libxml_disable_entity_loader(true)` has been called.
Here's a test script. IMHO, both assert()s should pass:
<?php
file_put_contents('/tmp/test.xml', '<doc><foo>bar</foo></doc>');
libxml_disable_entity_loader(false);
assert(simplexml_load_file('/tmp/test.xml')->foo == 'bar');
libxml_disable_entity_loader(true);
assert(simplexml_load_file('/tmp/test.xml')->foo == 'bar');
unlink('/tmp/test.xml');

Most likely this is not a bug. Those who disable the entity loader via libxml_disable_entity_loader() are dealing with an underlying problem with an unpatched libxml version.
Those who not have forgotten to implement their own entity loader (which is possible) which does not prevent from loading.
Same for the default entity loader being enabled.
Just my 2 cents.