Req #80357 [Opn]: Unable to re-enable entity loader without triggering a deprecation
| From: | jeremy at derusse dot com | Date: | Wed, 09 Dec 2020 10:12:06 +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-230950@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
User updated by: jeremy at derusse dot com
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:
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))
Previous Comments:
------------------------------------------------------------------------
[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?
------------------------------------------------------------------------
[2020-11-12 20:41:40] requinix@php.net
As far as I can tell, the whole point of the change was to deprecate the entire function and force
callers who want entity loading to do so at the time of loading (using LIBXML_NOENT). Eventually it
will be removed entirely, which would make a "libxml_entity_loader_disabled" function
pointless.
IMO this is one of those times when you should use @ to suppress the warning. I mean, if there is
code that disables the loader then it will be triggering the deprecation warning too, right?
------------------------------------------------------------------------
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