Req #80357 [Opn]: Unable to re-enable entity loader without triggering a deprecation

From: Date: Tue, 19 Jan 2021 12:27:40 +0000
Subject: Req #80357 [Opn]: Unable to re-enable entity loader without triggering a deprecation
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-231632@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=80357&edit=1 ID: 80357 Updated by: cmb@php.net Reported by: jeremy at derusse dot com Summary: Unable to re-enable entity loader without triggering a deprecation Status: Open Type: Feature/Change Request Package: *XML functions Operating System: All PHP Version: 8.0.0RC4 Block user comment: N Private report: N New Comment: After further consideration, it seems to me that calling libxml_disable_entity_loader(true) is generally a bad idea as of PHP 5.4.0 which introduced libxml_set_external_entity_loader(). That latter function as is doesn't resolve the mentioned library interoperability issues, though. Previous Comments: ------------------------------------------------------------------------ [2020-12-09 10:12:06] jeremy at derusse dot com Please open a new issue if you have a bug with libxml that does not disable the entity loader by default. This is not related to this bug: not triggering a deprecation on PHP8 note: on linux: PHP 8.0, libxml2 Version => 2.9.9 The provided code works with libxml_disable_entity_loader(true) and without libxml_disable_entity_loader (beware removing the call to libxml_disable_entity_loader has not the same effect than calling libxml_disable_entity_loader(false)) ------------------------------------------------------------------------ [2020-12-09 09:13:31] marek dot janata at seznam dot cz Not using deprecated libxml_disable_entity_loader leads to XXE vulnerability. My settings: Apache 2.4, Windows, PHP 8.0.0, libxml 2.9.10 Consider the following code: // --------------- $file = 'C:/secret/file.txt'; $xml = '<' . '?xml version="1.0" encoding="utf-8"?' .'>' .'<!DOCTYPE tag [<!ENTITY foo PUBLIC "bar" "'.$file.'" >]>' .'<tag>&foo;</tag>'; $prev = libxml_disable_entity_loader(TRUE); $doc = new DOMDocument(); $doc->preserveWhiteSpace = FALSE; $loadRes = $doc->loadXML($xml, LIBXML_NOENT); libxml_disable_entity_loader($prev); print $doc->saveXml(); // --------------- With libxml_disable_entity_loader, we get E_DEPRECATED, but the contents of local file is not loaded. Without libxml_disable_entity_loader, the code displays contents of local file. In our application, we want to allow local entities in XML document, so we have to call loadXml with LIBXML_NOENT flag. ------------------------------------------------------------------------ [2020-11-19 22:31:20] jeremy at derusse dot com Do you know if Not triggering E_DEPRECATED when the function is called with FALSE, appears is doable? ------------------------------------------------------------------------ [2020-11-13 10:30:12] cmb@php.net In hindsight, it might have been best to remove this functionality altogether, i.e. make libxml_disable_entity_loader() a NOP, but it's probably too late to do that now. Not issuing E_DEPRECATED if the function is called with FALSE, appears to be not unreasonable. ------------------------------------------------------------------------ [2020-11-13 07:55:27] jeremy at derusse dot com Thank you for the suggestion, but silencing the deprecation with an @ doesn't work: frameworks like Symfony, use error_handler to collect and logs deprecations. At the end the deprecation is not that silent. And I would like avoiding juggling with temporary error handlers to "just" silent a deprecation. What's about libxml_entity_loader_disabled(A_FALSE_CONSTANT) that re-enable the entity loader but without triggering the deprecation? ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=80357 -- Edit this bug report at https://bugs.php.net/bug.php?id=80357&edit=1

« previous php.bugs (#231632) next »