What to do with ext/xmlrpc?

  103703
January 9, 2019 12:28 cmbecker69@gmx.de ("Christoph M. Becker")
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
  103704
January 9, 2019 18:06 smalyshev@gmail.com (Stanislav Malyshev)
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
  103705
January 9, 2019 18:14 cmbecker69@gmx.de ("Christoph M. Becker")
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
  103706
January 9, 2019 18:34 pollita@php.net (Sara Golemon)
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
  103707
January 10, 2019 01:18 pierre.php@gmail.com (Pierre Joye)
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,
> > > -Sara >
  103710
January 10, 2019 11:00 Remi Collet <remi@fedoraproject.org>
--fg2yBWDZuZfKH2dmV5eJyIMvPMcUpVnvO
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

Le 09/01/2019 =C3=A0 13:28, Christoph M. Becker a =C3=A9crit=C2=A0:
> Hi! >=20 > The problem with ext/xmlrpc is that it relies on libxmlrpc-epi[1], whic= h
> 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 --fg2yBWDZuZfKH2dmV5eJyIMvPMcUpVnvO--
  103713
January 10, 2019 18:43 smalyshev@gmail.com (Stanislav Malyshev)
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
  106090
June 28, 2019 15:49 peterkokot@gmail.com (Peter Kokot)
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
  106091
June 28, 2019 15:57 cmbecker69@gmx.de ("Christoph M. Becker")
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
  106112
June 29, 2019 16:31 peterkokot@gmail.com (Peter Kokot)
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
  106124
July 1, 2019 15:15 cmbecker69@gmx.de ("Christoph M. Becker")
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