php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #80559 xmlrpc has no PECL releases to download
Submitted: 2020-12-28 20:17 UTC Modified: 2021-01-04 23:32 UTC
From: giunta dot gaetano at gmail dot com Assigned: cmb (profile)
Status: Closed Package: XMLRPC-EPI related
PHP Version: 7.4.13 OS: ubuntu
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: giunta dot gaetano at gmail dot com
New email:
PHP Version: OS:

 

 [2020-12-28 20:17 UTC] giunta dot gaetano at gmail dot com 
Description:
------------
Function xmlrpc_encode and xmlrpc_encode_request do encode all characters above 127 to their numeric entity representation, eg: chr(129) => ''

However there seems to be a bug for characters between 200 and 209 - for those the numeric entities generated are '' to ''.

The code in the source library, file 'xml_element.c' seems to have a bug in function create_xml_escape. The same bug would apply for characters 100 to 109, however that does not happen because those characters are not encoded as entities in the first place.

Test script:
---------------
echo xmlrpc_encode(chr(199).chr(200).chr(209).chr(210);


Expected result:
----------------
<?xml version="1.0" encoding="utf-8"?><params><param><value><string>&#199;&#200;&#209;&#210;</string></value></param></params>

Actual result:
--------------
<?xml version="1.0" encoding="utf-8"?><params><param><value><string>&#199;&#20;&#29;&#210;</string></value></param></params>

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2020-12-28 22:25 UTC] requinix@php.net
-Status: Open +Status: Not a bug
 [2020-12-28 22:25 UTC] requinix@php.net 
Upstream bug.

Bundled libxmlrpc-epi is good
http://git.php.net/?p=pecl/networking/xmlrpc.git;a=blob;f=libxmlrpc/xml_element.c;h=16787593516d492fcf720b0d3eea22934bae02f0;hb=refs/heads/master#l279

but this version on SourceForge does
https://sourceforge.net/p/xmlrpc-epi/git/ci/master/tree/src/xml_element.c#l290
 [2020-12-28 22:25 UTC] requinix@php.net 
*does not work (note the if c >= 10)
 [2020-12-29 10:16 UTC] giunta dot gaetano at gmail dot com 
Indeed I experienced this bug on Ubuntu's native php version, which uses a shared library for libxmlrpc-epi.

The problem has been reported upstream to Debian, and has been lingering in their bug tracker for a while :-( see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883747

Also, I managed to dig out the original bug report which led to this issue being fixed within php's source code: https://bugs.php.net/bug.php?id=28597

I know that the xmlrpc extension has been removed from php 8 and is thus probably in a strict 'maintenance only' mode, but would it make sense to try to make it easier for end users to install the non-buggy version from PECL?
 [2020-12-29 19:21 UTC] requinix@php.net
-Summary: xmlrpc_encode creates bad xml entities for chars 200 to 209 +Summary: xmlrpc has no PECL releases to download -Status: Not a bug +Status: Re-Opened -Assigned To: +Assigned To: cmb
 [2020-12-29 19:21 UTC] requinix@php.net 
> I know that the xmlrpc extension has been removed from php 8 and is thus
> probably in a strict 'maintenance only' mode, but would it make sense to try to
> make it easier for end users to install the non-buggy version from PECL?

@cmb?
 [2020-12-30 00:29 UTC] cmb@php.net 
From the respective RFC[1]:

| We are not doing users a favor by having an extension which relies
| on an unmaintained library, which may have serious issues and
| maybe even vulnerabilites, without signalling that issue. Since
| the problem with xmlrpc does not appear to be its functionality or
| API, but rather the lack of maintainance, a deprecation does not
| seem appropriate. Moving the extension to PECL is supposed to give
| users that signal, so they can reevaluate their use of the
| extension.

That said, I'll do a release ASAP, but I strongly suggest that
everybody who is still using this extension, to look out for an
alternative, perhaps <https://github.com/gggeek/polyfill-xmlrpc>.

[1] <https://wiki.php.net/rfc/unbundle_xmlprc>
 [2020-12-30 10:44 UTC] giunta dot gaetano at gmail dot com 
@cmb thanks.

As the developer behind polyfill-xmlrpc, I personally would use the ability to grab the xmlrpc-extension from PECL for just one thing: to install it on top of php 8 and run in that environment the compatibility tests for the polyfill.
In the meantime I managed to automate the installation of the extension from the pecl git master branch, so not having a release is less of an inconvenience.

I also added a link to polyfill-xmlrpc in a note in one page of the php manual, so there's that.

Last but not least: I am not aware of any security issue with the xmlrpc extension, but oh boy, writing a testsuite to make sure it's properly emulated in all corner cases made me find out that its handling of unexpected values is buggy as hell. I am not sure that polyfill-xmlrpc will ever reach an 'acceptable' level of compatibility... :-(
 [2021-01-04 23:32 UTC] cmb@php.net
-Status: Re-Opened +Status: Closed
 [2021-01-04 23:32 UTC] cmb@php.net 
xmlrpc 1.0.0RC1 has just been released[1].

> I am not sure that polyfill-xmlrpc will ever reach an
> 'acceptable' level of compatibility...

Bug compatibility might not be the best goal. :)

[1] <https://pecl.php.net/package-changelog.php?package=xmlrpc&release=1.0.0RC1>
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Thu Jul 03 15:01:34 2025 UTC