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 Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
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

Add a Patch

Pull Requests

Add a Pull Request

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-2024 The PHP Group
All rights reserved. 		Last updated: Fri Apr 19 09:01:27 2024 UTC