Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:107490 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 12210 invoked from network); 11 Oct 2019 09:11:02 -0000 Received: from unknown (HELO php-smtp3.php.net) (208.43.231.12) by pb1.pair.com with SMTP; 11 Oct 2019 09:11:02 -0000 Received: from php-smtp3.php.net (localhost [127.0.0.1]) by php-smtp3.php.net (Postfix) with ESMTP id BBCF62D201A for ; Thu, 10 Oct 2019 23:54:07 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp3.php.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS36024 206.123.114.0/23 X-Spam-Virus: No Received: from mail1.25mail.st (mail1.25mail.st [206.123.115.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp3.php.net (Postfix) with ESMTPS for ; Thu, 10 Oct 2019 23:54:06 -0700 (PDT) Received: from [10.0.1.86] (unknown [49.48.244.201]) by mail1.25mail.st (Postfix) with ESMTPSA id 6E66560356; Fri, 11 Oct 2019 06:54:00 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) In-Reply-To: Date: Fri, 11 Oct 2019 13:53:56 +0700 Cc: PHP Internals Content-Transfer-Encoding: quoted-printable Message-ID: <64166418-5944-475F-A171-A24AC066AE8F@koalephant.com> References: <5d976928.1c69fb81.db3a8.78daSMTPIN_ADDED_MISSING@mx.google.com> <413d377a-4ce1-a521-0cb4-5bb37e84c257@gmail.com> <6DFA91F7-0005-453E-A314-A5DFE1A4D3D3@newclarity.net> <82012CD7-088D-4010-922E-AD54186AE37A@newclarity.net> <67A49D41-A65F-4C07-82B2-1C19F17B2200@newclarity.net> <826c5050-6f7b-33c8-d856-60996b6210f3@gmail.com> <580781A9-5109-4B76-861A-4F9FCB6ABA61@koalephant.com> <8676F447-7B15-4FEC-B2EE-46CD6179D7B9@koalephant.com> To: Walter Parker X-Mailer: Apple Mail (2.3445.104.11) X-Envelope-From: Subject: Re: [PHP-DEV] Internals "camps" From: php-lists@koalephant.com (Stephen Reay) > On 11 Oct 2019, at 13:42, Walter Parker wrote: >=20 >=20 >=20 > On Thu, Oct 10, 2019 at 11:11 PM Stephen Reay = wrote: >=20 >=20 > > On 11 Oct 2019, at 12:40, Walter Parker wrote: > >=20 > > G > >=20 > > On Thu, Oct 10, 2019 at 10:10 PM Stephen Reay = > > wrote: > >=20 > >>=20 > >>=20 > >>> On 11 Oct 2019, at 02:59, Walter Parker wrote: > >>>=20 > >>> On Thu, Oct 10, 2019 at 10:36 AM Chase Peeler = > >> wrote: > >>>=20 > >>>>=20 > >>>>=20 > >>>> On Thu, Oct 10, 2019 at 1:30 PM Walter Parker > >> wrote: > >>>>=20 > >>>>>>=20 > >>>>>>=20 > >>>>>> No. The compromise is funding a ferry system. Or laying = Internet > >> between > >>>>>> them. Or a passenger pigeon mail route. > >>>>>>=20 > >>>>>> Sometimes compromise requires deep discussion about the = motivations > >> for > >>>>>> each side and coming to a lateral, mutually acceptable, = solution. > >>>>>>=20 > >>>>>> But we'd rather not discuss motivations and just bicker about = the > >>>>> surface > >>>>>> results. I.e., argue the X, rather than the Y, of these little = XY > >>>>> problems > >>>>>> we're solving. > >>>>>>=20 > >>>>>>=20 > >>>>>>=20 > >>>>> Build a ferry system is alternative to building bridge. I can = see that > >> as > >>>>> a > >>>>> compromise, I can also see that as a separate project created to = serve > >>>>> demand after the the bridge project is rejected. Where a ferry = system > >> is > >>>>> started because there is still demand for transit, just not = enough > >> demand > >>>>> to pay for a bridge. > >>>>>=20 > >>>>> With respect to the backtick proposal, what is the "ferry" = project? Do > >> we > >>>>> have to come up with one before we can cancel the "bridge" = project or > >> can > >>>>> we cancel the "bridge" project on its own merits and then = discuss a > >> future > >>>>> project that solves the actual underlying problem? > >>>>>=20 > >>>>> "Ferry" projects might be: more/better training on PHP, better > >>>>> documentation so that the backtick is no longer an "obscure" = feature to > >>>>> those that don't have a shell/Unix/Perl background, tooling to = warn > >> people > >>>>> when they misuse this feature. > >>>>>=20 > >>>>>=20 > >>>>>=20 > >>>> To the side that says "There is absolutely no reason we need to = go to, > >> or > >>>> communicate with, the island in the first place," a ferry project = isn't > >> a > >>>> compromise. The position of the "anti-bridge" builders isn't = because > >> they > >>>> are against building bridges - it's because they are against = spending > >>>> resources on attempts to get to the island in the first place. = The other > >>>> side might have valid arguments on why we need to get to the = island, > >> but, > >>>> just proposing different ways to get there isn't compromising = with the > >> side > >>>> that doesn't want to go there. > >>>>=20 > >>>=20 > >>> I think you may have just created a strawman for the anti-bridge > >> position. > >>> There are famous anti-bridge cases, like the Bridge to Nowhere in = Alaska > >>> (if you don't remember, there was an island in Alaska that had 50 = people > >>> and Senator Stevens wanted to replace the existing ferry system = with a > >> $398 > >>> million bridge). People complained about the bridge not because = they > >> wanted > >>> the islanders to to isolated, but because it was poor use of money = when > >>> there where bigger and more urgent problems. > >>>=20 > >>> To bring this back to PHP, is the backtick really a urgent problem = of > >>> enough magnitude that it justifies the cost of a BC break in = unknown > >> amount > >>> of PHP code that has been functional for years. If this proposal = passes > >>> (and the follow up to remove it which I'm certain will be = proposed), then > >>> this is one that leaves people on the island as they will either = be stuck > >>> on an old version of PHP or have to pay to update the code. This = pushes > >> the > >>> costs on them to solve a an existing issue that 20 years after it = was > >>> created and is now an issue because a new generation of coders, = unaware > >> of > >>> history, find the existing syntax not to there taste/a poor = design. Why > >> are > >>> we giving priority to people that haven't taken the time to = educate > >>> themselves over people that did and used programming style that = used to > >>> common? > >>>=20 > >>>=20 > >>>>=20 > >>>>=20 > >>>>> Walter > >>>>>=20 > >>>>> -- > >>>>> The greatest dangers to liberty lurk in insidious encroachment = by men > >> of > >>>>> zeal, well-meaning but without understanding. -- Justice Louis = D. > >>>>> Brandeis > >>>>>=20 > >>>>=20 > >>>>=20 > >>>> -- > >>>> Chase Peeler > >>>> chasepeeler@gmail.com > >>>>=20 > >>>=20 > >>>=20 > >>> -- > >>> The greatest dangers to liberty lurk in insidious encroachment by = men of > >>> zeal, well-meaning but without understanding. -- Justice Louis = D. > >> Brandeis > >>=20 > >>=20 > >> Hi Walter, > >>=20 > >> The RFC at the centre of this ridiculous string of analogies is = about one > >> thing: deprecate (i.e. show a deprecation message) about the = backtick > >> operator. > >>=20 > >> The RFC specifically doesn=E2=80=99t lay out a timeline for actual = removal, it > >> doesn=E2=80=99t even hint at =E2=80=9Cwell it=E2=80=99ll just be = automatically removed=E2=80=9D. > >>=20 > > I find disingenuous, the author of the RFC has said more than once = that > > removal is a goal of his. I think it is perfectly fair to look = ahead and > > view the process as a whole (the end goal). When walking to the edge = of a > > cliff, we don=E2=80=99t have to wait until we get to the edge to = understand that > > waking off the cliff is a mistake. > >=20 >=20 >=20 > It=E2=80=99s not disingenuous at all. Yes, the long-term goal is to = remove the backtick operator. That isn=E2=80=99t what this RFC is about = though. This RFC is about marking it as deprecated - indicating to users = that it is *likely* to be removed at some future date. >=20 >=20 > >=20 > >> So this RFC breaks *nothing*. > >>=20 > >> Yes, it does lead to the situation where it=E2=80=99s likely that a = followup RFC > >> will propose removing the (then) deprecated feature - perhaps 9.0, = perhaps > >> it=E2=80=99ll be discussed pre-9.0, and held off until 10.0? But = any such change > >> will then require *another* vote, with another round of discussions = and no > >> doubt ridiculous analogies. > >>=20 > >> And at that time, after several years of warnings about = deprecation, > >> Nikita or someone else will likely pop up with some analysis of = projects to > >> show usage *at the time*. > >>=20 > >> If the only reason to keep a dangerous operator is =E2=80=9Cwell a = small subset of > >> people use it=E2=80=9D, marking it as *deprecated* is how you = signal to those > >> people that the feature will likely be removed in a future version. > >>=20 > >>=20 > > Now you are assuming the conclusion. Once of the main debates here = is if > > the backtick is a dangerous thing. That has still to to be proven to = many > > people. > >=20 >=20 > If you don=E2=80=99t understand how exposing shell execution via a = single character operator is dangerous, I can=E2=80=99t help you. >=20 > If you can=E2=80=99t explain it , why do you expect others to support = you. Remember what Feynman said, if you can=E2=80=99t explain it, you = don=E2=80=99t really understand it. >=20 > Really, if you use backtick as a regular quote, the odds of breaking = anything are low. Even lower when you use code review, analysis tools = and a QA team worth a damn. =46rom a security point of view any shell = exec is a security risk. The number of characters required to execute it = is hardly important. > I suggest to re-examine your threat modules. I still have not seen = anything on this thread that amounts more than I feel it would make us = safer. >=20 >=20 >=20 >=20 > >=20 > >> The argument about =E2=80=9Cshell style scripts=E2=80=9D that are = on a server which > >> constantly gets updated to the newest release but never gets any > >> maintenance to the scripts is a ridiculous fantasy. > >>=20 > >> There is zero chance someone is dist-upgrading from one release to = the > >> next through enough versions that they get to one where the = distro-provided > >> php is such that backticks are actually removed, and yet the only = thing > >> that breaks is the backticks. > >>=20 > >>=20 > >>=20 > >> To be honest, what I really care about is people not breaking the = PHP > > applications that I=E2=80=99m currently using (Roundcube, = phpmyadmin, Wordpress ). > > I know that in the past I spent enough time fixing PHP code that = stopped > > working because of yet another BC change. That pace has slowed down = in > > recent years. If you and others really don=E2=80=99t think this is a = problem, I=E2=80=99ll > > let you and those others fix the issues in the future as they are = unlikely > > to effect me. Just don=E2=80=99t say =E2=80=9Cwe didn=E2=80=99t see = it coming=E2=80=9D. If I=E2=80=99m wrong, them > > I=E2=80=99m wrong and feel to follow up with me in the last 2020=E2=80= =99s when we know > > what has actually happened. > >=20 >=20 > =E2=80=A6 The whole point of deprecation notices is that nobody has = any reason to say =E2=80=9Cwe didn=E2=80=99t see it coming=E2=80=9D. = What part of that don=E2=80=99t you understand? >=20 > If a feature *of any kind* is listed as =E2=80=9Cdeprecated=E2=80=9D = by the vendor/project, and you=E2=80=99re still using it, the onus is on = *you* to fix it. That=E2=80=99s how deprecations work. >=20 >=20 > > Personally, I=E2=80=99m thinking of moving my backend work to = something else, like > > Go. Rob and his team seem to have a good handle on things. > >=20 >=20 > Great, good luck with that. >=20 > Thank you. I expect to have a blast learning a new language. >=20 >=20 >=20 >=20 > >=20 > > Cheers > >>=20 > >>=20 > >> Stephen > >=20 > >=20 > >=20 > > Good luck, hope you don=E2=80=99t eventually cause too much pain and = trouble with > > the BC breaks over the next few years. > >=20 > >=20 > > Walter > >=20 > >> -- > > The greatest dangers to liberty lurk in insidious encroachment by = men of > > zeal, well-meaning but without understanding. -- Justice Louis D. = Brandeis >=20 > --=20 > The greatest dangers to liberty lurk in insidious encroachment by men = of zeal, well-meaning but without understanding. -- Justice Louis D. = Brandeis Walter, Please read what I wrote, before responding. I didn=E2=80=99t say =E2=80=9C= I can=E2=80=99t explain it=E2=80=9D, I said =E2=80=9CI can=E2=80=99t = help you=E2=80=9D. The backtick operator looks a lot like a regular single-quoted string, = and in many other languages it is treated as such, or some derivative = thereof.=20 To expand on what I said before: If you don=E2=80=99t understand how exposing shell execution (something = most web applications will be unlikely to need) via an operator that is = visually similar to a string literal, I can=E2=80=99t help you, because = you=E2=80=99re clearly not willing to consider the actual implications. Suggesting that backticks are not a security risk, and "Even lower when = you use code review, analysis tools and a QA team worth a damn=E2=80=9D = is quite hypocritical given all the arguments made by people (including = yourself) about the =E2=80=9Ceffort=E2=80=9D required to replace = backticks with a `shell_exec` call. Are *YOU* offering to provide free = code reviews, analysis tools and a =E2=80=9CQA team worth a damn=E2=80=9D = to every project using PHP, just so the tiny percent of projects using = backticks legitimately don=E2=80=99t have to run one automated tool, = once, to convert them to the explicit alternative?