Re: [PHP-DEV] Internals "camps"

  107490
October 11, 2019 06:53 php-lists@koalephant.com (Stephen Reay)
> 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?
  107516
October 11, 2019 17:44 larry@garfieldtech.com ("Larry Garfield")
On Fri, Oct 11, 2019, at 1:53 AM, Stephen Reay wrote:
> > > > 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>
You know, I specifically pulled my comment out to a new subject line to respond very specifically to Zeev's "the other side" comment. I specifically tried to separate it from everyone talking past each other about a nitpicky issue that is only a topic of major discussion because it's being used as a proxy war for larger issues. Could y'all please go fight about analogies in another thread, rather than one that was explicitly trying to get away from that silliness? Much obliged. --Larry Garfield
  107518
October 11, 2019 18:21 walterp@gmail.com (Walter Parker)
Sure, sorry about that. I'm done with the silliness as we at an impasse.


Walter

On Fri, Oct 11, 2019 at 10:45 AM Larry Garfield <larry@garfieldtech.com>
wrote:

> > On Fri, Oct 11, 2019, at 1:53 AM, Stephen Reay wrote: > > > > > > > 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> > > You know, I specifically pulled my comment out to a new subject line to > respond very specifically to Zeev's "the other side" comment. I > specifically tried to separate it from everyone talking past each other > about a nitpicky issue that is only a topic of major discussion because > it's being used as a proxy war for larger issues. > > Could y'all please go fight about analogies in another thread, rather than > one that was explicitly trying to get away from that silliness? Much > obliged. > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis