On 14.08.2017 at 13:04, Zeev Suraski wrote: > On Sunday, August 13, 2017 6:53 PM, Nikita Popov wrote: > >> On Sun, Aug 13, 2017 at 5:08 PM, Christoph M. Becker >> <cmbecke...@gmx.de> wrote: >> >>> On 11.08.2017 at 15:15, Nikita Popov wrote: >>> >>>> I'm wondering if it might be time to remove (i.e. deprecate and >>>> move to PECL) the wddx extension? >>> >>> Hmm, that would leave a pretty useless extension in PECL. An >>> alternative might be to remove support for objects and the wddx >>> session serialization handler. This might even be done as bug >>> fix if a respective ini option would be introduced. We could >>> still move the extension to PECL afterwards. >> >> I'm only suggesting a move to PECL because that seems to be our >> standard procedure when removing extensions. >> >> Given that WDDX as a data interchange format seems pretty much >> dead, I don't think it's worth trying to "fix" it in some way, >> especially a way that breaks backwards compatibility. Even without >> the additional security considerations, I would say it's long >> overdue to unbundle this extension. > > I would lean towards doing both: > > 1. Move it to PECL as you suggest - > regardless of the security element, as you say, it's long overdue for > unbundling. > > 2. Disable the object support in it as Christoph and Stas > suggest, so that it's not completely useless (i.e. inherently > insecure) in PECL. Admittedly I haven't looked at the code but I > imagine that can't be too complex..?
FWIW, I've did this in my wddx branch, see <https://github.com/cmb69/php-src/tree/wddx>. > Given the security implications (the positive ones, that is), I would > seriously consider doing that for 7.2 despite the very late point in > time. It might be sensible to only *deprecate* object unserialization for 7.2, and to (re)move the WDDX extension in 7.3. After all, we already tell users that `wddx_deserialize()` should not be used on untrusted input: * <http://docs.php.net/manual/en/intro.wddx.php> * <http://docs.php.net/manual/en/function.wddx-deserialize.php> Either way, we most certainly need an RFC to proceed… -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
