Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107489
MIME-Version: 1.0
References: <5d976928.1c69fb81.db3a8.78daSMTPIN_ADDED_MISSING@mx.google.com>
 <CAF+90c9uXdqJsTizLCca-AswenZDv9-6yw=ranATp3XoutHyxw@mail.gmail.com>
 <DM5PR06MB285747B847DE2D7320758C05DE9A0@DM5PR06MB2857.namprd06.prod.outlook.com>
 <e69fb3de-df5f-f77e-ad4e-61ea30185c5c@lsces.uk> <CAG9XoMR9DhKDwS1moH_9pjDNyZQ70ER5_stNs_GxQFucZ+ar7A@mail.gmail.com>
 <413d377a-4ce1-a521-0cb4-5bb37e84c257@gmail.com> <6DFA91F7-0005-453E-A314-A5DFE1A4D3D3@newclarity.net>
 <CAHN63oN3cgGaaWhYhLUVBAgRsi7d-eLODfhLGBOJetFh98zWQg@mail.gmail.com>
 <D2050867-9A1B-45D1-A51E-F7AFEE47DD69@newclarity.net> <CAJHtznwX-V8KKSyqir-BQBeaovP3+a6-EoafOFxpgGwAqth3sg@mail.gmail.com>
 <82012CD7-088D-4010-922E-AD54186AE37A@newclarity.net> <CAJHtznweQuiXZff=O=d1=JNZCLU-+dJ=eZ49Ev0bc9zp1aC1Ag@mail.gmail.com>
 <ed3411a8-2be7-4555-be8e-adb45462d992@www.fastmail.com> <67A49D41-A65F-4C07-82B2-1C19F17B2200@newclarity.net>
 <826c5050-6f7b-33c8-d856-60996b6210f3@gmail.com> <CC00FB75-E929-4AE6-9E95-A38FA53DA6BB@newclarity.net>
 <CAPKYkKy8zDJpvST_YeqmnLBwFeBYcKKZY-nj4KyGKGOdG9XSjw@mail.gmail.com>
 <CAEYWF=7rTHdjaJTtnXVYts-xuhyOJ5OpHiWMnBUu1nhcrzDATQ@mail.gmail.com>
 <CAMPTd_C4p6YbT_Rnd8aZ7t66gnu=gZ=BguKn5G6N-MkzW5sPfw@mail.gmail.com>
 <CAPKYkKzHZnTRRA1MUZxtj80epUqGv9zHhJNVuTVoh5_x8roXYQ@mail.gmail.com>
 <CAMPTd_BBqOFcOO-zHhNoPekRQrfsK9yReisUpYjRYvu77k7-7A@mail.gmail.com>
 <580781A9-5109-4B76-861A-4F9FCB6ABA61@koalephant.com> <CAMPTd_Aon4mwvHqs44FTJabc2V14yv5dhjEnskhTYKY0Da5Gng@mail.gmail.com>
 <8676F447-7B15-4FEC-B2EE-46CD6179D7B9@koalephant.com>
In-Reply-To: <8676F447-7B15-4FEC-B2EE-46CD6179D7B9@koalephant.com>
Date: Thu, 10 Oct 2019 23:42:07 -0700
Message-ID: <CAMPTd_BCoHgZmtwxiA+bpsWhBRyHk_kMn7SSP2v_2iDhr_PAsg@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>, Stephen Reay <stephen@koalephant.com>
Content-Type: multipart/alternative; boundary="000000000000b72f3c05949cd176"
Subject: Re: [PHP-DEV] Internals "camps"
From: walterp@gmail.com (Walter Parker)

--000000000000b72f3c05949cd176
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 motivation=
s
> >> 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 syst=
em
> >> 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" featur=
e
> 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 t=
o,
> >> 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 spendin=
g
> >>>> 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 t=
he
> >> 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 wh=
en
> >>> 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 pass=
es
> >>> (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 push=
es
> >> 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, unawa=
re
> >> of
> >>> history, find the existing syntax not to there taste/a poor design. W=
hy
> >> 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 m=
en
> >> 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=E2=80=99t lay out a timeline for actual rem=
oval, it
> >> doesn=E2=80=99t even hint at =E2=80=9Cwell it=E2=80=99ll just be autom=
atically removed=E2=80=9D.
> >>
> > 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 a=
nd
> > 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 unders=
tand that
> > waking off the cliff is a mistake.
> >
>
>
> It=E2=80=99s not disingenuous at all. Yes, the long-term goal is to remov=
e 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.
>
>
> >
> >> So this RFC breaks *nothing*.
> >>
> >> Yes, it does lead to the situation where it=E2=80=99s likely that a fo=
llowup 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 s=
uch change
> >> will then require *another* vote, with another round of discussions an=
d
> 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 =E2=80=9Cwell a sma=
ll subset
> of
> >> people use it=E2=80=9D, marking it as *deprecated* is how you signal t=
o 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 i=
f
> > the backtick is a dangerous thing. That has still to to be proven to ma=
ny
> > people.
> >
>
> 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.
>

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 reall=
y 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 =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.
> >>
> >> 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 thin=
g
> >> that breaks is the backticks.
> >>
> >>
> >>
> >> To be honest, what I really care about is people not breaking the PHP
> > applications that I=E2=80=99m currently using (Roundcube, phpmyadmin, W=
ordpress
> ).
> > I know that in the past I spent enough time fixing PHP code that stoppe=
d
> > 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 pr=
oblem,
> 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.
> >
>
> =E2=80=A6 The whole point of deprecation notices is that nobody has any r=
eason 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?
>
> If a feature *of any kind* is listed as =E2=80=9Cdeprecated=E2=80=9D by t=
he
> vendor/project, and you=E2=80=99re still using it, the onus is on *you* t=
o fix it.
> That=E2=80=99s how deprecations work.
>
>
> > 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.
> >
>
> Great, good luck with that.
>

Thank you. I expect to have a blast learning a new language.



>
> >
> > Cheers
> >>
> >>
> >> Stephen
> >
> >
> >
> > Good luck, hope you don=E2=80=99t eventually cause too much pain and tr=
ouble with
> > the BC breaks over the next few years.
> >
> >
> > Walter
> >
> >> --
> > The greatest dangers to liberty lurk in insidious encroachment by men o=
f
> > 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. Brandei=
s

--000000000000b72f3c05949cd176--