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
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
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
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
Hi,
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/phpxmlrpcI 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
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
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