Hi Dan, > Am 16.08.2019 um 08:07 schrieb Dan Mahoney <[email protected]>: > > Martin and others, > > I don’t have a good answer for this, other than to say that PHP has been the > bane of my existence for a while. As a admin, I’ve lost more hours and sleep > on PHP scripts than any other tool. PHP is the programming language that > brought us WordPress, MovableType, PHPNuke, PostNuke, PHPBB, and Drupal. And > I’ve had users running sites with all of them. Shoddy security code and all. > > The “best” way for running PHP (with the privileges of your webserver, as an > apache module) was a security nightmare, and burned me badly. > > PHP’s own builtin security “features” (for example, open_basedir or safe > mode) fail to do what they want to do (and much canned code refuses to work > with them turned on), while things like allow_url_fopen enabled by default > have made even the simplest php-based homepage (where PHP is used as little > more than a repacement for mod_include) vulnerable to reflection attacks. > > Lots of php-based code also has had a horrible history of version upgrades. > > Upgrading PHP burned me badly as well, as code would mysteriously break on > shared hosting systems, and my users would complain about things breaking > overnight, or errors being sent to stdout (i.e. the browser). The PHP devs > would randomly deprecate functions, which would break otherwise-working older > code. > > Let me give you one simple example: Gallery. Gallery 1, which doesn’t > require a database backend. There’s no real good replacement I’ve found for > it, but it’s coded in a hard to read/upgrade style. I’ve secured it by > disabling comments, as well as limiting access to the login/admin functions > with additional .htaccess restrictions, as well as carefully monitoring the > logs and file sizes. > > The solution I ultimately arrived for keeping php both current *and* > compatible was that using SuPHP, I can enable multiple versions of PHP to run > concurrently, even back to php4, as well as limiting the permissions php > scripts have down to the owner, so that each site/vhost has its own php.ini, > users, and permissions. I get here by building php’s CGI/CLI versions from > scratch, and keeping copies of my ./configure arguments handy for each > version, so I can easily rebuild them all if there’s a shared library change. > This also lets me easily swap in PHP versions to test if something will > break, rather than replacing/upgrading the one ports installs. > > Sent from my iPad
Thank you for your input. While I agree that PHP, in general, has been and still is a source of lots of security issues, I do not think this is the central point in this debate. There might be a high probability of security issues that are PHP related for all I know, but again, the real question is: Why drop a package that has just had recent security updates after a couple of weeks? I pointed out that I do not think lack of upstream development is in and of itself sufficient grounds for doing so. At the very least, while it may be unwise to use a now obsolete version of PHP, I doubt if an argument along the lines of 'We removed this from ports. It's for your own good' is a very good one. (For a number of reasons). The only other arguments I got so far seem to be about resources. I can understand that. With limited resources you have to prioritize and something will have to give. Now, in a reply to Adam, I asked specifically if there were pointers that would help me evaluate how much effort is really involved. (My working theory being that I so far underestimate the work required to do this.) Also, I asked if people were open to letting a group of people interested in doing so continue to maintain an old version of php so that it does not have to be removed from ports. Kurt suggested that as a feasible way forward and I agree. Earlier, Adam seemed open to discussing a way forward as well, but I am not sure that still is the case. Since I do not yet feel comfortable that I correctly estimate the amount of work, if enough people can be found to volunteer for this, but I remain hopeful. All this notwithstanding, would you be willing to exchange hints & ideas about securing (as far as possible) PHP setups some more, off-list? I'd like to ask some more about your approach. Best, Martin _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[email protected]"
