Re: Internals "camps"

> On 11 Oct 2019, at 13:42, Walter Parker <walterp@gmail.com> wrote: > > > > On Thu, Oct 10, 2019 at 11:11 PM Stephen Reay <stephen@koalephant.com> wrote: > > > > On 11 Oct 2019, at 12:40, Walter Parker <walterp@gmail.com> wrote: > > > > G > > > > On Thu, Oct 10, 2019 at 10:10 PM Stephen Reay <stephen@koalephant.com> > > wrote: > > > >> > >> > >>> On 11 Oct 2019, at 02:59, Walter Parker <walterp@gmail.com> wrote: > >>> > >>> On Thu, Oct 10, 2019 at 10:36 AM Chase Peeler <chasepeeler@gmail.com> > >> wrote: > >>> > >>>> > >>>> > >>>> On Thu, Oct 10, 2019 at 1:30 PM Walter Parker <walterp@gmail.com> > >> wrote: > >>>> > >>>>>> > >>>>>> > >>>>>> No. The compromise is funding a ferry system. Or laying Internet > >> between > >>>>>> them. Or a passenger pigeon mail route. > >>>>>> > >>>>>> Sometimes compromise requires deep discussion about the motivations > >> for > >>>>>> each side and coming to a lateral, mutually acceptable, solution. > >>>>>> > >>>>>> 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. > >>>>>> > >>>>>> > >>>>>> > >>>>> 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. > >>>>> > >>>>> 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? > >>>>> > >>>>> "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. > >>>>> > >>>>> > >>>>> > >>>> 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. > >>>> > >>> > >>> 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. > >>> > >>> 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? > >>> > >>> > >>>> > >>>> > >>>>> Walter > >>>>> > >>>>> -- > >>>>> The greatest dangers to liberty lurk in insidious encroachment by men > >> of > >>>>> zeal, well-meaning but without understanding. -- Justice Louis D. > >>>>> Brandeis > >>>>> > >>>> > >>>> > >>>> -- > >>>> Chase Peeler > >>>> chasepeeler@gmail.com > >>>> > >>> > >>> > >>> -- > >>> The greatest dangers to liberty lurk in insidious encroachment by men of > >>> zeal, well-meaning but without understanding. -- Justice Louis D. > >> Brandeis > >> > >> > >> Hi Walter, > >> > >> 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. > >> > >> The RFC specifically doesn’t lay out a timeline for actual removal, it > >> doesn’t even hint at “well it’ll just be automatically removed”. > >> > > 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’t have to wait until we get to the edge to understand that > > waking off the cliff is a mistake. > > > > > It’s not disingenuous at all. Yes, the long-term goal is to remove the backtick operator. > That isn’t 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. > > > > > >> So this RFC breaks *nothing*. > >> > >> Yes, it does lead to the situation where it’s likely that a followup RFC > >> will propose removing the (then) deprecated feature - perhaps 9.0, perhaps > >> it’ll 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. > >> > >> 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*. > >> > >> If the only reason to keep a dangerous operator is “well a small subset of > >> people use it”, marking it as *deprecated* is how you signal to those > >> people that the feature will likely be removed in a future version. > >> > >> > > 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. > > > > If you don’t understand how exposing shell execution via a single character operator is > dangerous, I can’t help you. > > If you can’t explain it , why do you expect others to support you. Remember what Feynman > said, if you can’t explain it, you don’t really understand it. > > 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. From 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. > > > > > > > >> The argument about “shell style scripts” 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. > >> > >> 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. > >> > >> > >> > >> To be honest, what I really care about is people not breaking the PHP > > applications that I’m 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’t think this is a problem, I’ll > > let you and those others fix the issues in the future as they are unlikely > > to effect me. Just don’t say “we didn’t see it coming”. If I’m wrong, them > > I’m wrong and feel to follow up with me in the last 2020’s when we know > > what has actually happened. > > > > … The whole point of deprecation notices is that nobody has any reason to say “we didn’t > see it coming”. What part of that don’t you understand? > > If a feature *of any kind* is listed as “deprecated” by the vendor/project, and you’re > still using it, the onus is on *you* to fix it. That’s how deprecations work. > > > > Personally, I’m thinking of moving my backend work to something else, like > > Go. Rob and his team seem to have a good handle on things. > > > > Great, good luck with that. > > Thank you. I expect to have a blast learning a new language. > > > > > > > > Cheers > >> > >> > >> Stephen > > > > > > > > Good luck, hope you don’t eventually cause too much pain and trouble with > > the BC breaks over the next few years. > > > > > > Walter > > > >> -- > > The greatest dangers to liberty lurk in insidious encroachment by men of > > zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis > > -- > 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’t say “I can’t explain it”, I said “I can’t help you”. 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. To expand on what I said before: If you don’t 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’t help you, because you’re 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” is quite hypocritical given all the arguments made by people (including yourself) about the “effort” required to replace backticks with a shell_exec call. Are *YOU* offering to provide free code reviews, analysis tools and a “QA team worth a damn” to every project using PHP, just so the tiny percent of projects using backticks legitimately don’t have to run one automated tool, once, to convert them to the explicit alternative?