Date: Fri, 16 Aug 2019 09:27:32 +0200 From: =?utf-8?Q?Martin_Waschb=C3=BCsch?= <martin@waschbuesch.de> To: FreeBSD Ports <freebsd-ports@freebsd.org> Subject: Re: PHP version retirement Message-ID: <57D05F4F-9379-4760-8BEE-7B432A6008DE@waschbuesch.de> In-Reply-To: <97336C1A-6743-462B-984A-6C513A5B9CED@prime.gushi.org> References: <CF1F28D6-1072-4BE6-B124-A97DE43FA4E6@waschbuesch.de> <97336C1A-6743-462B-984A-6C513A5B9CED@prime.gushi.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Dan, > Am 16.08.2019 um 08:07 schrieb Dan Mahoney <danm@prime.gushi.org>: >=20 > Martin and others, >=20 > I don=E2=80=99t 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=E2=80=99= 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=E2=80=99ve had users = running sites with all of them. Shoddy security code and all. >=20 > The =E2=80=9Cbest=E2=80=9D way for running PHP (with the privileges of = your webserver, as an apache module) was a security nightmare, and = burned me badly. >=20 > PHP=E2=80=99s own builtin security =E2=80=9Cfeatures=E2=80=9D (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. >=20 > Lots of php-based code also has had a horrible history of version = upgrades. >=20 > 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. >=20 > Let me give you one simple example: Gallery. Gallery 1, which = doesn=E2=80=99t require a database backend. There=E2=80=99s no real = good replacement I=E2=80=99ve found for it, but it=E2=80=99s coded in a = hard to read/upgrade style. I=E2=80=99ve 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. >=20 > 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=E2=80=99s 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=E2=80=99s 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. >=20 > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?57D05F4F-9379-4760-8BEE-7B432A6008DE>