Everything

php

What to do with ext/xmlrpc?

php.internals

Christoph Becker

7 years ago

Hi!

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.

Thoughts?

[1] <https://sourceforge.net/projects/xmlrpc-epi/>
[2]
<https://github.com/php/php-src/blob/php-7.3.1/ext/xmlrpc/libxmlrpc/xmlrpc.h#L47>
[3] <https://sourceforge.net/projects/xmlrpc-epi/files/xmlrpc-epi-base/>
[4] <https://github.com/php/php-src/blob/php-7.3.1/NEWS#L89-L90>

--
Christoph M. Becker

Stas Malyshev

7 years ago

Hi!

> So unless a maintainer steps forward, it might be best to deprecate
> and/or unbundle ext/xmlrpc.

I think we need to do ask for a maintainer, and if nobody steps up,
declare it unsupported and unbundle.

--
Stas Malyshev
smalyshev@gmail.com

Christoph Becker

7 years ago

On 09.01.2019 at 19:06, Stanislav Malyshev wrote:

>> So unless a maintainer steps forward, it might be best to deprecate
>> and/or unbundle ext/xmlrpc.
>
> I think we need to do ask for a maintainer, and if nobody steps up,
> declare it unsupported and unbundle.

We still have no official “Call for Maintainership” template, and nobody
replied on <https://externals.io/message/102556#103256> so far.

--
Christoph M. Becker

Sara Golemon

7 years ago

On Wed, Jan 9, 2019 at 6:28 AM Christoph M. Becker <cmbecker69@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.

-Sara

Pierre Joye

7 years ago

Hi,

On Thu, Jan 10, 2019, 1:34 AM Sara Golemon <pollita@php.net wrote:

> On Wed, Jan 9, 2019 at 6:28 AM Christoph M. Becker <cmbecker69@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,

Remi Collet

7 years ago

Le 09/01/2019 à 13:28, Christoph M. Becker a écrit :

> Hi!
>
> 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

As for mcrypt, I think we should move it to PECL
to clearly state, this should be avoid.

ext/imap should follow the same road.

BTW, if we want to keep this extension, we need to consider the bundled
library as a fork, maintained by US (and drop support to build using the
system library, if present)

So, any new volunteer to maintain this extension, will also have to
maintain the library.


Remi

Stas Malyshev

7 years ago

Hi!

> ext/imap should follow the same road.
>
> BTW, if we want to keep this extension, we need to consider the bundled
> library as a fork, maintained by US (and drop support to build using the
> system library, if present)
>
> So, any new volunteer to maintain this extension, will also have to
> maintain the library.

This looks unlikely, so we shouldn't count on it happening. I think we
should just move them to PECL and if somebody shows up, we can always
move it back.

--
Stas Malyshev
smalyshev@gmail.com

Peter Kokot

7 years ago

On Thu, 10 Jan 2019 at 19:43, Stanislav Malyshev <smalyshev@gmail.com> wrote:

>
> Hi!
>
> > ext/imap should follow the same road.
> >
> > BTW, if we want to keep this extension, we need to consider the bundled
> > library as a fork, maintained by US (and drop support to build using the
> > system library, if present)
> >
> > So, any new volunteer to maintain this extension, will also have to
> > maintain the library.
>
> This looks unlikely, so we shouldn't count on it happening. I think we
> should just move them to PECL and if somebody shows up, we can always
> move it back.
>
> --
> Stas Malyshev
> smalyshev@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Hello, sorry for bumping this one. Is the ext/xmlrpc extension also on
the list to be unbundled maybe for PHP-7.4?

--
Peter Kokot

Christoph Becker

7 years ago

On 28.06.2019 at 17:49, Peter Kokot wrote:

> On Thu, 10 Jan 2019 at 19:43, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>>
>>> ext/imap should follow the same road.
>>>
>>> BTW, if we want to keep this extension, we need to consider the bundled
>>> library as a fork, maintained by US (and drop support to build using the
>>> system library, if present)
>>>
>>> So, any new volunteer to maintain this extension, will also have to
>>> maintain the library.
>>
>> This looks unlikely, so we shouldn't count on it happening. I think we
>> should just move them to PECL and if somebody shows up, we can always
>> move it back.
>
> Hello, sorry for bumping this one. Is the ext/xmlrpc extension also on
> the list to be unbundled maybe for PHP-7.4?

AFAIK, it isn't.  Sorry for not having pursued this.

--
Christoph M. Becker

Peter Kokot

7 years ago

On Fri, 28 Jun 2019 at 17:57, Christoph M. Becker <cmbecker69@gmx.de> wrote:

>
> On 28.06.2019 at 17:49, Peter Kokot wrote:
>
> > On Thu, 10 Jan 2019 at 19:43, Stanislav Malyshev <smalyshev@gmail.com> wrote:
> >>
> >>> ext/imap should follow the same road.
> >>>
> >>> BTW, if we want to keep this extension, we need to consider the bundled
> >>> library as a fork, maintained by US (and drop support to build using the
> >>> system library, if present)
> >>>
> >>> So, any new volunteer to maintain this extension, will also have to
> >>> maintain the library.
> >>
> >> This looks unlikely, so we shouldn't count on it happening. I think we
> >> should just move them to PECL and if somebody shows up, we can always
> >> move it back.
> >
> > Hello, sorry for bumping this one. Is the ext/xmlrpc extension also on
> > the list to be unbundled maybe for PHP-7.4?
>
> AFAIK, it isn't.  Sorry for not having pursued this.
>
> --
> Christoph M. Becker

Then I can create an RFC to unbundle it from the core and move it
together with the libxmlrpc library fork into PECL. Having
unmaintained extensions in the core and marked as experimental for the
last 18 years is not good I think. Is there enough time to do all this
until July 22nd (7.4 feature freeze)?

--
Peter Kokot

Christoph Becker

7 years ago

On 29.06.2019 at 18:31, Peter Kokot wrote:

> On Fri, 28 Jun 2019 at 17:57, Christoph M. Becker <cmbecker69@gmx.de> wrote:
>>
>> On 28.06.2019 at 17:49, Peter Kokot wrote:
>>
>>> On Thu, 10 Jan 2019 at 19:43, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>>>>
>>>>> ext/imap should follow the same road.
>>>>>
>>>>> BTW, if we want to keep this extension, we need to consider the bundled
>>>>> library as a fork, maintained by US (and drop support to build using the
>>>>> system library, if present)
>>>>>
>>>>> So, any new volunteer to maintain this extension, will also have to
>>>>> maintain the library.
>>>>
>>>> This looks unlikely, so we shouldn't count on it happening. I think we
>>>> should just move them to PECL and if somebody shows up, we can always
>>>> move it back.
>>>
>>> Hello, sorry for bumping this one. Is the ext/xmlrpc extension also on
>>> the list to be unbundled maybe for PHP-7.4?
>>
>> AFAIK, it isn't.  Sorry for not having pursued this.
>
> Then I can create an RFC to unbundle it from the core and move it
> together with the libxmlrpc library fork into PECL. Having
> unmaintained extensions in the core and marked as experimental for the
> last 18 years is not good I think. Is there enough time to do all this
> until July 22nd (7.4 feature freeze)?

I think it's too late to start an RFC targeting PHP 7.4, since there is
a minimum of two weeks for discussion and two weeks for voting.

--
Christoph M. Becker