While I think it is not generally much useful to whine about other people's code quality without providing accurate bug reports (and possibly patches), I mostly agree with the previous comment about the PEAR repository.
Not 100% of the PEAR code is flawed, of course, but the quality varies wildly.
To make matters worse, the PEAR team thinks it's a good idea to import pre-existing libs into the repository, without asking explicit cooperation of the actual lib maintainers.
The benefits coming from a wider exposure of the code (since newbees tend to always use PHP code from PEAR, after all it's hosted on php.net, right?) and an auto-updater script are more than balanced by the impact of having to maintain two seaparate code forks, with separate bug reports etc...
Prominent examples of this situation are the XMLRPC (imported from phpxmlrpc) and SOAP (imported from NUSOAP) packages.
Having said that, the exposed bug has been sleeping in the code since circa 1999, and is not an artifact coming from the PEAR team. In 1999 security was less a concern in general and for PHP in particular (register_globalls=Off would coem much later).
I fully agree that rebuilding the code from scratch today, 'eval' would have to be banned, but hey, no one yet stepped up for the complete rewrite.
BTW: complete details about the problem and possible remedies are now online at http://phpxmlrpc.sourceforge.net#security
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds