> On 11 Oct 2019, at 13:42, Walter Parker <walt...@gmail.com> wrote:
>
>
>
> On Thu, Oct 10, 2019 at 11:11 PM Stephen Reay <step...@koalephant.com> wrote:
>
>
> > On 11 Oct 2019, at 12:40, Walter Parker <walt...@gmail.com> wrote:
> >
> > G
> >
> > On Thu, Oct 10, 2019 at 10:10 PM Stephen Reay <step...@koalephant.com>
> > wrote:
> >
> >>
> >>
> >>> On 11 Oct 2019, at 02:59, Walter Parker <walt...@gmail.com> wrote:
> >>>
> >>> On Thu, Oct 10, 2019 at 10:36 AM Chase Peeler <chasepee...@gmail.com>
> >> wrote:
> >>>
> >>>>
> >>>>
> >>>> On Thu, Oct 10, 2019 at 1:30 PM Walter Parker <walt...@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
> >>>> chasepee...@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?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
