Hi, On Thu, Jan 10, 2019, 1:34 AM Sara Golemon <poll...@php.net wrote:
> On Wed, Jan 9, 2019 at 6:28 AM Christoph M. Becker <cmbecke...@gmx.de> > wrote: > > > The problem with ext/xmlrpc is that it relies on libxmlrpc-epi[1], which > > looks abandoned. Even worse, we're bundling a modified 0.51[2], while > > the latest version is 0.54.1[3]. This is exacerbated by the fact that > > the system library is usually build against libexpat, but the bundled > > library is likely to be build against libxml2 using our compat layer. > > > > We most recently fixed two security issues[4], but it is likely not > > clear whether these may affect latest system libraries as well, and > > there are more issues. > > > > So unless a maintainer steps forward, it might be best to deprecate > > and/or unbundle ext/xmlrpc. > > > > IMO, xmlrpc is one of those extensions which could trivially be > re-implemented as pure PHP code. It would depend on ext/dom or similar for > serde, but everything else is just business logic that can be lifted out of > the runtime and probably made WAY better. In fact, a quick google says > something in that spirit already exits: > https://packagist.org/packages/phpxmlrpc/phpxmlrpc > > I don't think we need to put energy into finding maintainers for extensions > which don't need to exist. Send it to Siberia, afaic. > > You are right. Not worth the effort. > Also Pear xmlrpx (client and server) implements both with and without ext xmlrpc support and seems to be maintained somehow (seeing commits in the last months) best, > > > -Sara >
