From owner-freebsd-ports@freebsd.org Fri Aug 16 07:27:39 2019 Return-Path: Delivered-To: freebsd-ports@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4FA7CC2B54 for ; Fri, 16 Aug 2019 07:27:39 +0000 (UTC) (envelope-from martin@waschbuesch.de) Received: from relay02.waschbuesch.it (relay02.waschbuesch.it [IPv6:2a00:cba0:100::232]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.waschbuesch.it", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 468vzZ1qYGz3PWj for ; Fri, 16 Aug 2019 07:27:37 +0000 (UTC) (envelope-from martin@waschbuesch.de) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=waschbuesch.de; s=dkim; h=Message-Id:In-Reply-To:To:References:Date:Subject :Mime-Version:Content-Transfer-Encoding:Content-Type:From:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=HgyKKh4Tp4Fw3Gkqw4HBF4/Tauh4UePLGr9tHVcnEgU=; b=K8i3cg0KY3sNx0y12YEdZGxxdH /bd8+9LucypNFdLmp4m5kVdg4Ekc2wIzT4fdpoS8ZxlmtqVvEbp8ZCZ2b4/ymieOsqNFgZdZq8s3u t3UaG85Cm8+vhxV3ZlZeywZTk3+uD3RaZA81siifqCpsztw+Yk7HJW0LR2ODnB63NHm8=; Received: by relay02.waschbuesch.it with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim) (envelope-from ) id 1hyWe5-00039m-7v for freebsd-ports@freebsd.org; Fri, 16 Aug 2019 07:27:33 +0000 From: =?utf-8?Q?Martin_Waschb=C3=BCsch?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: PHP version retirement Date: Fri, 16 Aug 2019 09:27:32 +0200 References: <97336C1A-6743-462B-984A-6C513A5B9CED@prime.gushi.org> To: FreeBSD Ports In-Reply-To: <97336C1A-6743-462B-984A-6C513A5B9CED@prime.gushi.org> Message-Id: <57D05F4F-9379-4760-8BEE-7B432A6008DE@waschbuesch.de> X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 468vzZ1qYGz3PWj X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=waschbuesch.de header.s=dkim header.b=K8i3cg0K; dmarc=pass (policy=none) header.from=waschbuesch.de; spf=pass (mx1.freebsd.org: domain of martin@waschbuesch.de designates 2a00:cba0:100::232 as permitted sender) smtp.mailfrom=martin@waschbuesch.de X-Spamd-Result: default: False [-5.98 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[waschbuesch.de:s=dkim]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MV_CASE(0.50)[]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[2.3.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.a.b.c.0.0.a.2.list.dnswl.org : 127.0.5.2]; DKIM_TRACE(0.00)[waschbuesch.de:+]; DMARC_POLICY_ALLOW(-0.50)[waschbuesch.de,none]; NEURAL_HAM_SHORT(-0.99)[-0.995,0]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-1.79)[ipnet: 2a00:cba0::/32(-4.96), asn: 21476(-3.96), country: DE(-0.01)]; ASN(0.00)[asn:21476, ipnet:2a00:cba0::/32, country:DE]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 07:27:39 -0000 Hi Dan, > Am 16.08.2019 um 08:07 schrieb Dan Mahoney : >=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