Re: [PHP-DEV] RFC: execution opcode file without php source code file

[Walter Parker]

On Fri, Oct 2, 2020 at 10:08 AM David Rodrigues  wrote:
>
> Hello folks,
>
> Instead of an opcode without a php source file, that I imagine is to
> protect the code itself, why not a method to encrypt phar files (not like a
> password). I do not know if exists a secure method to decrypt to execute
> only, without reveals the original source code, but maybe it could be done.
> So opcode could be generated based on encrypted phar to give more speed.
>
>

The flaw with decryption is that the image will have to get the
decryption key from somewhere. The history of the DVD industry over
the past 25 years has shown that getting that key to an untrusted
device and then keeping it secret is much harder than it looks (when
people care enough to go after the key, even hardware locks can be
made to fail). Or look at the phone industry, even phones with
hardware & software locked crypto get broken open.
Note, if the device is trusted, then encryption and decryption are not
needed (as you would then be able to trust the device to not give out
the source code).

Also, note that reverse engineering (decompling) raw binaries is a
thing (there are tools to do that). You need to decide on you threat
model for your code to decide on how much it is worth to lock your
code.

Walter


-- 
The greatest dangers to liberty lurk in insidious encroachment by men
of zeal, well-meaning but without understanding.   -- Justice Louis D.
Brandeis

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] T_PAAMAYIM_NEKUDOTAYIM is terrible, are we sure we're OK with it?

[Walter Parker]

We read phil's post years ago (it is from 2013).
Do you have anything new to contribute to the discourse other than
posting a link to a post from 7 years ago?

If so, you should present that and not old web pages .


Walter

On Tue, Jul 28, 2020 at 7:31 PM Ryan Jentzsch  wrote:
>
> https://phil.tech/2013/wtf-is-t-paamayim-nekudotayim/



-- 
The greatest dangers to liberty lurk in insidious encroachment by men
of zeal, well-meaning but without understanding.   -- Justice Louis D.
Brandeis

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV][RFC] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

[Walter Parker]

On Wed, Jun 10, 2020 at 3:14 PM Sara Golemon  wrote:

> On Wed, Jun 10, 2020 at 3:33 PM Ryan Jentzsch 
> wrote:
>
> > OMG the trolling continues even today with this nonsense. Disappointing.
> >
>
> Oh yes. And histrionics will certainly deescalate that issue.
>
>
> > "...yes, it is broken, people have to Google or ask around for a very
> > unclear error message when for the most part errors are (and should be)
> > self explanatory
> >
>
> You know what shows up unambiguously in a google search? "Paamayim
> Nekudotayim".
> You know what ISN'T unambiguous in a google search? "Double Colon"
> You know who don't have an excuse to say "Google is hard"? Software
> engineers.
>
>
> Can I say Double Thumbs Up to the comment about Google searches?
Anybody doing software development without using a search engine is typing
with one hand.
When making requests, stop inventing bad ideas.
Do you actually know developers that write software without ever using a
search engine to look up errors?
Given how most docs have moved online, that seems like people doing things
the hard way without good reason.
Assuming you have actually met these people, who have not even bothered to
even learn the basics of life in the modern age, why must we change to
support them?
Couldn't we just put a line in some doc somewhere about how using search
engines is a vital piece of development technology somewhere between using
print statements and how to use a debugger?




> > ...Two things are broken: Either the token is named badly, or the token
> > names shouldn’t show up in error messages at all and be replaced with
> > something a bit more friendly.
> >
>
> Token names shouldn't show up.  Everyone is agreeing with that statement.
> Universally.  Let's fix that problem rather than create new ones by not
> addressing the underlying issue.
>
> Once again I plead for logic and sanity. At least have the courage to put
> > it to a vote.
> >
> > Absolutely. Put it to a vote.  I've got my "no" all locked and loaded.
>
> -Sara
>


-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] Internals "camps"

[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 
wrote:

>
> On Fri, Oct 11, 2019, at 1:53 AM, Stephen Reay wrote:
> >
> >
> > > On 11 Oct 2019, at 13:42, Walter Parker  wrote:
> > >
> > >
> > >
> > > On Thu, Oct 10, 2019 at 11:11 PM Stephen Reay 
> wrote:
> > >
> > >
> > > > On 11 Oct 2019, at 12:40, Walter Parker  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  wrote:
> > > >>>
> > > >>> On Thu, Oct 10, 2019 at 10:36 AM Chase Peeler <
> chasepee...@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

Re: [PHP-DEV] Internals "camps"

[Walter Parker]

On Thu, Oct 10, 2019 at 11:11 PM Stephen Reay 
wrote:

>
>
> > On 11 Oct 2019, at 12:40, Walter Parker  wrote:
> >
> > G
> >
> > On Thu, Oct 10, 2019 at 10:10 PM Stephen Reay 
> > wrote:
> >
> >>
> >>
> >>> On 11 Oct 2019, at 02:59, Walter Parker  wrote:
> >>>
> >>> On Thu, Oct 10, 2019 at 10:36 AM Chase Peeler 
> >> wrote:
> >>>
> >>>>
> >>>>
> >>>> On Thu, Oct 10, 2019 at 1:30 PM Walter Parker 
> >> 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 le

Re: [PHP-DEV] Internals "camps"

[Walter Parker]

G

On Thu, Oct 10, 2019 at 10:10 PM Stephen Reay 
wrote:

>
>
> > On 11 Oct 2019, at 02:59, Walter Parker  wrote:
> >
> > On Thu, Oct 10, 2019 at 10:36 AM Chase Peeler 
> wrote:
> >
> >>
> >>
> >> On Thu, Oct 10, 2019 at 1:30 PM Walter Parker 
> 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
> >>>
> >>
> >>
> >

Re: [PHP-DEV] Internals "camps"

[Walter Parker]

On Thu, Oct 10, 2019 at 3:27 PM Mark Randall  wrote:

> On 10/10/2019 23:04, Walter Parker wrote:
> > If this truly is the problem that you say it is, there should be plenty
> of
> > documentation online as to the issues that it has cause. Maybe you could
> > post some of the better cases (as the the responsibility of the person
> > suggesting the change to provide evidence that the change is a good
> idea).
>
> The top comment on our own documentation website upvoted more than a
> hundred times is people using it by accident :-)
>
>
> Thank you for finally providing some research data on the subject. Now we
know that in the last 13 years 103 have upvoted a comment in our
documentation about someone making a typo in their code by typing ` and it
was not simple to figure out (as they were not using an editor with syntax
highlighting).

FYI, I just Google'd ` and the first two links do give the name of the
item. The second is link to stack overflow that documents what it means and
how to use.

I admit that I've been programming since before PHP was invented. I started
with Unix shells and Perl decades ago, so ` is not a foot gun for me. It
sounds like it foot gun for many others. What I still don't know is if the
rate of foot shooting of a feature that you say is rarely used these days
outweighs the cost of breaking older code that does use it. Personally, I
think you are underestimating the cost and trouble of fixing it, but I'll
admit that I could be wrong. As I stopped supporting other people's PHP,
the costs of this vote should have little to no impact on me personally. If
It does pass, I hope the costs and trouble are as small as you seem to
think they are.


Walter



> --
> 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

Re: [PHP-DEV] Internals "camps"

[Walter Parker]

On Thu, Oct 10, 2019 at 1:27 PM Mark Randall  wrote:

> On 10/10/2019 20:59, Walter Parker wrote:
> > They will either be stuck  on an old version of PHP or have to pay to
> update the code.
>
> If you're getting stuck on a island after being given 4 or 5 years
> warning that the bridge to it will be closed, after being pointed to the
> ferry, given free tickets to that ferry, and being told it will continue
> to run long after, that's your own fault.
>
>
> Ok, that's something I had not realized, you and the other supports of
this RFC are offering to fix other people's PHP code for free. Given that,
I have far few objections to this RFC. That is what free tickets on the
ferry means...


> > 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.
>
>
> History does not mean it was a good idea at the time, and even if it
> was, that doesn't mean it's a good idea now. Times move on. Your
> argument could easily be reversed...
>
> Personal opinion.


> An old generation of coders, stuck in their ways, inflexible, preferring
> what they know rather than changing with the times for the greater good.
>
> Personal opinion and maybe an insult.


>
> > 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?
>
>
> We're assuming that in a general purpose programming languages, most
> programmers expect a function call to look like a function call, and not
> a string.
>
> Still looks like another opinion, but I can see where people get confused.
You don't know the number of times I say backslash and people type /
instead of \. Personally I think using \ for namespaces in PHP was a
horrible idea. Why did PHP use the character that almost all modern langues
use for escape as a name separator. I know they used it because it was the
best of the bad items available.



> We're assuming that people don't just go from never having touched PHP,
> to expert level, knowing all its quirks and secrets, within a few hours.
>
> We're assuming that there's a heck of a lot more to stewardship of the
> language than backwards compatibility.
>
>
>
> So let's look at it from the perspective of what we can do...
>
> We can either a) Find a way to reach out to every PHP programmer in the
> world and let them know that there's these special operators that look
> like a string, but actually aren't, and they do something that can be
> really dangerous, and they'll probably never see it but god help them if
> it's there and they miss it.
>
> or
>
> b) We add one line of code and warn people that we're eventually going
> to remove a rarely used and poorly understood syntax, and people should
> at some point in the next 4 or 5 migrate to the much more obvious
> shell_exec.
>
> Still mostly personal opinion here. You have still not bought any facts or
research other than your personal opinion and research that I assume you
did with your local working group.


> By writing the RFC, it's pretty obvious which one I think is the best
> and most realistic course of action.
>
> That much is clear. What is not clear is how much that opinion is shared
with the average programmer with a few years of experience. Most coding
syntax is poorly understood by the beginning programmer. For the beginning
programmer, I think $username = `whoami` and $username =
shell_exec("whoami") would be equally confusing because you would have
explain what a shell was, what exec was, maybe even what a function was.
For backtick, you would tell them if you want the output from a command you
run on the command line, enclose the command in backticks (they look like
this `) and it will give you that value. In the PHP documentation for
shell_exec, it links to backtick. The backtick documentation linkes to
shell_exec.

If this truly is the problem that you say it is, there should be plenty of
documentation online as to the issues that it has cause. Maybe you could
post some of the better cases (as the the responsibility of the person
suggesting the change to provide evidence that the change is a good idea).



> Mark Randall
>
> --
> 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

Re: [PHP-DEV] Internals "camps"

[Walter Parker]

On Thu, Oct 10, 2019 at 11:04 AM Mark Randall  wrote:

> On 10/10/2019 18:30, Walter Parker wrote:
> > "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.
>
> Unfortunately most of those are out of our hands.
>
> While it would certainly be great if we could better educate everyone,
> such things are beyond the power of internals to do, and while we could
> improve the documentation, we're not in a position to tell everyone that
> new information is there, and even still, that wouldn't change that it's
> too easy to miss for the power it possesses.
>
> While a warning would be something, PHP's warnings don't actually
> prevent anything. By the time you see them, the problem has usually
> already occurred.
>
> That leaves us with the choice that's within our power, deprecation and
> eventual removal of backticks in favour of something that's much more
> obvious in its intent and much less easy to miss.
>
> Mark Randall
>
>
So what I read here is that we need to undergo the costs of removing
backticks to make up for the problem that people have stopped widely using
them and the fact that too many programmers have stopped reading the
manual. This appears to similar to the deletionist campaigns on WIkiPedia
(where people delete pages if the subject isn't famous enough). I've found
those distasteful.

Could we first do some research to figure out if this actually a
significant issue or if it is minor annoyance? I think that is one of the
problems here. One group thinks this is a major issue that should be
addressed now, the other thinks that it isn't a problem and hasn't seen any
justification that rises about the level of opinion of few people.


Walter




-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] Internals "camps"

[Walter Parker]

On Thu, Oct 10, 2019 at 10:36 AM Chase Peeler  wrote:

>
>
> On Thu, Oct 10, 2019 at 1:30 PM Walter Parker  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

Re: [PHP-DEV] Internals "camps"

[Walter Parker]

>
>
> 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.


Walter

-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[Walter Parker]

On Tue, Oct 8, 2019 at 2:25 PM M. W. Moe  wrote:

> Hello,
>
> what you write and advocate for can't be heard by a vast majority of people
> here; because they are just not North-American; somehow
> that's a very interesting trait; most of people despise `kind` moralism.
>
>
> On Tue, Oct 8, 2019 at 2:14 PM Mike Schinkel  wrote:
>
> > > On Oct 8, 2019, at 4:29 PM, Lynn  wrote:
> > > My middle ground is a vote, regardless of outcome.
> >
> > If a vote is the middle ground then why the need to participate in any
> > discussion?
> >
> > Also, how is a vote a middle ground? A vote ensures that one sides wins
> > and the other side looses.  IOW, a zero-sum game.
> >
> > Why does it not make better sense to actively look for ways to optimize
> > outcomes so that the most people can win?  For example...
> >
> > > This RFC is pretty simple, a deprecation + removal in a later patch,
> > there's not much to compromise on the implementation.
> >
> > A compromise might be "NO agreement to remove in a later patch."
> >
> > Why does it not make sense to offer that up as a consolation to the one
> > asking for deprecation?  If they accepted and changed the RFC, then more
> > people could get a "win."
> >
> > > If people think a deprecation should not be done or if it's not worth
> > it, a vote is the way to show that opinion.
> > > If there are enough reasons to not deprecate them, the voting process
> > will show this and the RFC will be rejected.
> >
> > I have noticed on this list much discussion of the "minority vs. the
> > majority."  But that is a red-herring. There are a small number of people
> > who have a vote (~200?) whereas there are over 5 million PHP developers
> and
> > even more PHP stakeholders who have no vote.
> >
> > In other words, when internals@ votes unanimously on an RFC they still
> > only represent ~0.004% of PHP stakeholders.  Basically an aristocracy.
> >
> > So while a vote is a way to share an opinion, it is not representative of
> > the opinions of those it may affect.  It is a shame that the PHP voting
> > process has no objective way to incorporate userland concerns except when
> > some act as their proxy. Which is not the same as userland having
> explicit
> > representatives with a vote.
> >
> > > PS. We need a CoC.
> >
> > 100% agree.
> >
> > -Mike
> >
> > P.S. I also think PHP needs an agreed statement of principles (Mission,
> > Vision and Values.) With said statement RFCs could be evaluated to
> > determine if they align with PHP's previously-agreed principles. Such a
> > statement could be revised from time to time, but having one would
> resolve
> > a lot of contentious debates before they happen.
> >
> >
> >
>

The original proposal reads like: I don't understand it, I've talked to
other that don't understand it. Not understand something makes learning the
language harder, so we should get rid of the feature.

How is this not Mark Twain's plan for the Improvement of Spelling in the
English language?

A Plan for the Improvement of Spelling in the English Language

By Mark Twain

For example, in Year 1 that useless letter “c” would be dropped to be
replased either by “k” or “s”, and likewise “x” would no longer be part of
the alphabet. The only kase in which “c” would be retained would be the
“ch” formation, which will be dealt with later. Year 2 might reform “w”
spelling, so that “which” and “one” would take the same konsonant, wile
Year 3 might well abolish “y” replasing it with “i” and iear 4 might fiks
the “g/j” anomali wonse and for all.

Generally, then, the improvement would kontinue iear bai iear with iear 5
doing awai with useless double konsonants, and iears 6-12 or so modifaiing
vowlz and the rimeiniing voist and unvoist konsonants. Bai iear 15 or sou,
it wud fainali bi posibl tu meik ius ov thi ridandant letez “c”, “y” and
“x”—bai now jast a memori in the maindz ov ould doderez —tu riplais “ch”,
“sh”, and “th” rispektivili.

Fainali, xen, aafte sam 20 iers ov orxogrefkl riform, wi wud hev a lojikl,
kohirnt speling in ius xrewawt xe Ingliy-spiking werld.



Walter

-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[Walter Parker]

On Tue, Oct 8, 2019 at 1:23 PM M. W. Moe  wrote:

> @Mike Schinkel,
>
> a middle ground about/with silliness? there is none, for people in their
> right mind; should people really find/force
> themselves into conciliation about non-sense? I don't think so and mostly;
> I have no say about deprecating that;
> but is that a priority? does it harm anyone? someone have died from
> backtick infection, it must be according to some?
> and so on. Don't see where there is a heated topic; solely a reminder about
> reality and facts.
>
> Regards.
>
> On Tue, Oct 8, 2019 at 1:12 PM Mike Schinkel  wrote:
>
> > My, my this is a heated topic.
> >
> > I am commenting in part because I do not have a dog in this hunt.  I am
> > okay leaving it, I am okay if it is deprecated.  There are other things
> for
> > PHP that I care far more about than this RFC.  So...
> >
> > I am wondering if everyone participating in this discussion would be
> > willing to ask themselves "Is there any middle ground where I can respond
> > in a way that is win-win for everyone involved?" rather than retreating
> to
> > each other's respective corners and fighting as if to the death?
> >
> > If I did not know better I would think this group was filled with members
> > of the US Congress because of the unwillingness to compromise and seek
> > common ground.
> >
> > For example, would those who oppose this RFC change to support it if this
> > was changed from:
> >
> > > Although the deprecation notice itself will carry no backwards
> >
> > > compatibility changes, this RFC is written with the intent that the
> >
> > > backtick operator would eventually be removed in a later version
> >
> >
> > To this?:
> >
> > The deprecation notice will carry no backwards compatibility changes.
> > In addition this RFC is explicitly not recommending removal of the
> > backtick operator in a later version. To remove it — if ever desired —
> > will require an additional RFC to be passed.
> >
> >
> > Maybe the above resolves the objections against this RFC?  Or maybe the
> > above makes it useless in the minds of those who want to get rid of
> > backtick? But this specific FRC does not matter to me
> >
> > The point however, is can we not work to some form of happy medium rather
> > than everyone fighting a zero sum game?
> >
> > -Mike
> > #jmtcw
>

 What would a happy medium be? backticks working 50% of the time?
This is like someone being pregnant, either you are or you are not there is
no half pregnant.
Either backticks work like they have in shells for decades or they don't
work.
What's the point of deprecating them without a plan to remove them? A
notice without future action is a bad idea, as it sets standard that some
deprecation messages will not be acted upon.


Walter

-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Walter Parker]

On Tue, Aug 6, 2019 at 2:55 PM Claude Pache  wrote:

>
>
> > Le 6 août 2019 à 20:46, Nikita Popov  a écrit :
> >
> > On Tue, Aug 6, 2019 at 1:34 PM G. P. B. 
> wrote:
> >
> >> The voting for the "Deprecate short open tags, again" [1] RFC has begun.
> >> It is expected to last two (2) weeks until 2019-08-20.
> >>
> >> A counter argument to this RFC is available at
> >> https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags
> >>
> >> Best regards
> >>
> >> George P. Banyard
> >>
> >> [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2
> >>
> >
> > Side-note: Even if this RFC fails, we should probably still make it an
> > error to use  we
> > may flip the default to off at some later point in time. The current
> > default being "on" despite their use being discouraged is half the
> trouble.
> >
> > Nikita
>
>
> That would mean in particular that XML documents could no longer be
> preprocessed by PHP without boilerplate around its `` declaration.
> I doubt that this is a more acceptable breaking change than deprecating
> short_tags.
>
> —Claude
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> Why would you want to use PHP's preprocessor for XML?
Why not use the right tool for the job? Such as an XML processor that could
also do schema validation? PHP has XML processing packages. It has been a
while since I did XML processing, but I don't remember the packages being
all that difficult to use. Is this a mixing data and code into the same
file problem? Like HTML files that have PHP embedded directly in the file?
Or this about stuffing PHP inside of XML documents?


Walter

-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV][DISCUSSION] Multilingual PHP

[Walter Parker]

I also am old enough to have used/remember using BASIC. I remember German
and Japanese friends that wrote in BASIC. It was interesting to see German
programs where all the keywords were in English and all the text was in
German. The Japanese was even more strange as the system had to switch
between the code pages for ASCII/LATIN and the one for the Japanese
Language.

Today to get something other an ASCII/LATIN, we would have to support
Unicode for source code. Does PHP currently work if Unicode is used for
identifiers?


Walter

On Thu, Apr 11, 2019 at 2:36 PM Bruce Weirdan  wrote:

> On Fri, Apr 12, 2019 at 12:17 AM Benjamin Morel 
> wrote:
>
> > This may be harder for people having a native language with a different
> > alphabet, though.
> >
>
> That's unlikely to be a problem. Even to get to the PHP manual you have to
> type `www.php.net` (or `google.com` if you want to google something),
> so it implies you have a way to enter latin characters. Keyboard layout
> switching is a problem solved decades ago.
>
> --
>   Best regards,
>   Bruce Weirdan mailto:
> weir...@gmail.com
>


-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] phpenmod/phpdismod

[Walter Parker]

On Sat, Feb 2, 2019 at 1:06 PM Peter Kokot  wrote:

> >> 3. Do you know where is the source code of these two scripts? When the
> >> upstream script gets updated it would be then useful to copy/paste
> >> changes into php-src. So the main development should be happening
> >> upstream anyway. Meaning away from the PHP.
> >
> >
> > I don't know what to say on that.
>
> P.S. I've found sources at Debian mainstream:
> https://sources.debian.org/src/php-defaults/69/php-helper/
>
> Overall, I think this might be too Debian specific tool. PECL is
> something that works in similar way. And it installs entire extension
> from scratch together with compiling... PECL approach is something
> that PHP should go into. Or, the more taboo way - Composer installable
> extensions. There was some work done on that but it got stuck because
> it is very large change and now nobody knows how to do that from that
> step. Basically, a Composer plugin might be a better start with this.
> Except that here we need to understand that PHP packages on Linux
> distributions are already compiled and prepared for faster
> installation, so installing extensions with PECL is a way different
> approach compared to a more comfortable ways using
> apt/yum/dnf/pacman/brew...
>
> --
> Peter Kokot
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
If you can make it work on MacOS, Windows, and the BSDs, then great.
Otherwise, it should be left to the Linux distributions.


Walter
-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] Unifying logical operators

[Walter Parker]

On Tue, Jul 10, 2018 at 7:58 PM, Alice Wonder  wrote:

> On 07/10/2018 07:20 PM, Ryan wrote:
>
>> On Tue, Jul 10, 2018 at 2:26 AM, Walter Parker  wrote:
>>
>>
>>> That is a matter of style, as I find $a = func() or die more clear that
>>> the version that uses ||
>>>
>>> Not chaining stuff together is a third style.
>>>
>>> This feels like a Python PEP request. By that I mean that Python wants to
>>> have only one way to do any one task. Perl style is there’s more than one
>>> way to do it.
>>>
>>> PHP has been a mix of these styles.
>>>
>>> The big question I have is how much PHP code will break due to an
>>> enforced
>>> style requirement?.
>>>
>>>
>> As I said in the OP, out of the top 30 GitHub repositories (the first page
>> on the API since I couldn't figure out how to get to the second), there
>> was
>> only one line that would require a change (and it was copy-pasted from the
>> manual).  Obviously there's no way to truly know how many times it's used
>> in non-public code, but I'll expand my GitHub search and report back some
>> more solid metrics.
>>
>
> Using github may not be the most reliable method.
>
>
There are 67 Million repositories on GitHub, is picking the top 30 PHP
projects a representative sample of PHP use across the Internet?
80% of web servers where the back end language was known had PHP according
to a recent survey.
Picking 30 popular open source projects might bias the results of what you
think is going in PHP usage.


Look at what is most popularly used in composer dependencies.
>
> For example, I know xor is used in PHP Codesniffer which while likely not
> often part of deployed code is very often a devel dependency.
>
> I think phpunit also uses xor and is also very popular.
>
> I use xor myself but my use is purely hobby (I have a pseudo-RNG written
> in PHP that can take any source of data, random or not, and pass it through
> a filter that makes it pass pRNG tests - showing that passing tests doesn't
> mean a random source is necessarily random enough for cryptography)
>
> Anyway as I believe you have already conceded, nuking xor would require
> many projects used a lot to have to change.
>
>
>
> --
> 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

Re: [PHP-DEV] Unifying logical operators

[Walter Parker]

On Mon, Jul 9, 2018 at 9:03 PM Ryan  wrote:

> Hello all!  Longtime PHP user, first-time contributor to internals (sorry
> if I screw anything up)!
>
> I'd like to propose either the deprecation (7.next - likely 7.4 at this
> point) and removal (8.0) of the T_LOGICAL_OR (or), T_LOGICAL_AND (and), and
> T_LOGICAL_XOR (xor) tokens, or aliasing them to ||, &&, and !=
> respectively.
>
> The behaviours of the two sets of logical operators are very similar (it's
> incredibly unclear how $x or $y would differ from $x||$y).  They perform
> almost identically except for the fact that the former set has a precedence
> lower that the assignment, null coalescing, and ternary operators[1].  The
> page on logical operators[2] states that the reason the two variations
> exist is that they "operate at different precedences" (which isn't a reason
> for existence, but rather a statement of differences).
>
> Example #1 on the logical operators page[2] gives an example of this
> difference:
> $e = false || true; // true
> $f = false or true; // false
>
> Because of the difference of precedence, the second line is evaluated as
> ($f = false) or true;
>
> In my mind (and in the mind of every programmer I've spoken to about this),
> this violates the principle of least astonishment[3].  The assignment
> operator is usually thought to be the lowest level of precedence other than
> parenthesis (as a typical statement would be "do some thing, then assign
> its value to this varible").
>
> This[4] stackoverflow question sheds some light on the intent of the
> alternative operators - they are used for "control flow" in the style of
> Ruby's "unless" operator[5]:
>
> defined("SOME_CONSTANT") or die("SOME_CONSTANT was not defined");
>
> However, this behaviour has nothing to do with the difference of precedence
> - rather this is due to short circuiting.
>
> The only difference between the two (unless there are interactions I'm not
> aware of with the ternary or null coalescing operator) is the precedence
> with the assignment operator, causing the return value to be assigned
> without respect to the conditional.  I ran a quick (possibly imperfect)
> script on GitHub's top 30 repositories, and of the usages of the
> T_LOGICAL_* operators all but this one[6] operated equivalently to the
> symbolic ones:
> $gdImage = @imagecreatetruecolor(120, 20) or die('Cannot Initialize new GD
> image stream');
>
> In this case, the result of imagecreatetruecolor is intended to be placed
> in $gdImage, or if it is falsey, die with an error.  This could be
> rewritten as:
> ($gdImage = @imagecreatetruecolor(120, 20)) || die('Cannot Initialize new
> GD image stream');
>
> Or, in my opinion, more cleanly:
> $gdImage = @imagecreatetruecolor(120, 20);
> if(!$gdImage) die('Cannot Initialize new GD image stream');
>

That is a matter of style, as I find $a = func() or die more clear that the
version that uses ||

Not chaining stuff together is a third style.

This feels like a Python PEP request. By that I mean that Python wants to
have only one way to do any one task. Perl style is there’s more than one
way to do it.

PHP has been a mix of these styles.

The big question I have is how much PHP code will break due to an enforced
style requirement?

Removing them for style seems like it would be a big BC break. Aliasing
them might lead to more subtle bugs in legacy code.

>
> I've written a very rough draft RFC here[7] - and I would love feedback.
> If it's taken well I can put it up on the wiki.
>
> Thanks,
> Ryan "Iggy" Volz
>
> [1]: http://php.net/manual/en/language.operators.precedence.php
> [2]: http://php.net/manual/en/language.operators.logical.php
> [3]: https://en.wikipedia.org/wiki/Principle_of_least_astonishment
> [4]: https://stackoverflow.com/a/5998351
> [5]:
>
> https://www.tutorialspoint.com/ruby/ruby_if_else.htm#Ruby%20unless%20modifier
> [6]:
>
> https://github.com/PHPOffice/PhpSpreadsheet/blob/aa5b0d0236c907fd8dba0883f3ceb97cc52e46ec/samples/Basic/25_In_memory_image.php#L24
> - likely copied from
> http://php.net/manual/en/function.imagecreatetruecolor.php
> [7]: https://github.com/iggyvolz/Unifying-Operators-RFC
>
-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] PHP 7.2.0 Released

[Walter Parker]

Deleted without reading...

On Tue, Dec 5, 2017 at 9:09 AM, li...@rhsoft.net <li...@rhsoft.net> wrote:

>
>
> Am 05.12.2017 um 17:45 schrieb Walter Parker:
>
>> Lists, I give you the same advice. I know and use SSL Labs, I been a
>> subscriber to Ivan's mailing list for years. Older versions of Openssl had
>> a default list of +ALL, -aNULL, -eNULL as the default list of ciphers
>>
>
> yes
>
> Before DES was removed in the new versions of openssl, that means the list
>> included things like DES and RC4
>>
>
> don't matter because no somehow recent client would have negotiated
> DES/RC4 with a config like below even if the SSLCipherSuite would contain
> RC4/DES at the end of the list
>
> SSLHonorCipherOrder On
> SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:
> ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:
> ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-CHACHA20-POLY1305:ECDH
> E-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-
> ECDSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-
> AES256-SHA384:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:
> ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-
> GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-SHA256:
> DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:
> AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA
>
> That is why server admins always spelled out long lists of ciphers, to
>> guarantee that weak ciphers would not appear on older installs. I found
>> this information by reading the code bases themselves, where did you find
>> your information?
>>
>
> frankly you are saying exactly the same as i did
>
> the point is that for nearly a deacde servers take care of negotiated
> ciphers and when tomorrow one of them like AES-CBC with several
> vulerabilities in the past years becomes problematic like you even was
> advised to prefer RC4 instead block-ciphers for the timewinodow of a large
> amount unfixed clients you can as serveradmin migitate the problem
>
> but only if the client is not PHP which thinks to outsmart client openssl
> as well as servers configuration
>
> this also makes initiatives like https://fedoraproject.org/wiki
> /Changes/CryptoPolicy useless and everything reacts faster than wait for
> the next PHP point release!
>
> I'm done with you. You don't understand and worse you don't want to
>> understand but think you understand. You just admitted to that. Please stop
>> until you get proper training as someone else on this list might make the
>> same mistakes that you are
>>
> yes, please stop to repsond to any of my mails, especially stop offlist
> mails
>
>
> --
> 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

Re: [PHP-DEV] PHP 7.2.0 Released

[Walter Parker]

On Tue, Dec 5, 2017 at 12:54 AM, li...@rhsoft.net <li...@rhsoft.net> wrote:

>
>
> Am 05.12.2017 um 06:52 schrieb Walter Parker:
>
>> On Mon, Dec 4, 2017 at 6:27 PM, li...@rhsoft.net <mailto:li...@rhsoft.net>
>> <li...@rhsoft.net <mailto:li...@rhsoft.net>> wrote:
>>
>> Am 05.12.2017 um 01:19 schrieb Walter Parker:
>>
>> Oh, I see, this not about the actual change (the protocol
>> version). This is about when using PHP on the client side, it
>> does not support all/enough of the modern cipher suite list.
>>
>> Now that we have identified the problem in question, this should
>> help you when you create your RFC to fix issues with the cipher
>> suite list.
>>
>> FYI, the client and server send lists of ciphers that they
>> support to each other, the server does an AND and picks the
>> highest cipher in on the list. If the client sends only NULL,
>> then NULL is the only valid cipher. OpenSSL has default list
>> which includes weak ciphers (such as DES), so using the default
>> list is bad idea
>>
>> this is not true at all and that's why you use tools like
>> https://www.ssllabs.com/ssltest/ and SSLHonorCipherOrder as
>> serveradmin for many years if you care
>> about TLS at all
>>
>> also the default openssl cipherlist is not just random
>>
>> as you can see it prefers the ECDSA AES-GCM followed by the RSA
>> AES-GCM and after the ECDHE it continues with other GCM ciphers na
>> dthe DES/CBC stuff is at a place in the list which never is selected
>> these days
>>
>> Your link doesn't say what you think it does
>>
>
> which one?
> https://www.ssllabs.com/ssltest/
>
> sorry, but if you don't know what ssllab does and how it is used by
> serveradmins to make sure clients using best possible encryption you are
> hardly in the position making comments like "OpenSSL has default list which
> includes weak ciphers (such as DES), so using the default list is bad idea"
> and instead abusive responses you could have entered the url of a TLS
> webserver
>
> Your follow up comments also appear to have little relevance to the topic
>> at hand.
>>
>
> correct and the reason is that i needed to give you some basic education
> how ciphers in the real world are negotiated
>
> Could someone please let me know if Lists ever get back on topic with
>> responses to the questions and statements made, rather than charging
>> sideways off the field?
>>
> go and provocate someone else when you make clueless statements like
> "OpenSSL has default list which includes weak ciphers (such as DES), so
> using the default list is bad idea"
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> Lists, I give you the same advice. I know and use SSL Labs, I been a
subscriber to Ivan's mailing list for years. Older versions of Openssl had
a default list of +ALL, -aNULL, -eNULL as the default list of ciphers.
Before DES was removed in the new versions of openssl, that means the list
included things like DES and RC4. That is why server admins always spelled
out long lists of ciphers, to guarantee that weak ciphers would not appear
on older installs. I found this information by reading the code bases
themselves, where did you find your information?

I'm done with you. You don't understand and worse you don't want to
understand but think you understand. You just admitted to that. Please stop
until you get proper training as someone else on this list might make the
same mistakes that you are.



-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] PHP 7.2.0 Released

[Walter Parker]

On Mon, Dec 4, 2017 at 6:27 PM, li...@rhsoft.net <li...@rhsoft.net> wrote:

>
>
> Am 05.12.2017 um 01:19 schrieb Walter Parker:
>
>> Oh, I see, this not about the actual change (the protocol version). This
>> is about when using PHP on the client side, it does not support all/enough
>> of the modern cipher suite list.
>>
>> Now that we have identified the problem in question, this should help you
>> when you create your RFC to fix issues with the cipher suite list.
>>
>> FYI, the client and server send lists of ciphers that they support to
>> each other, the server does an AND and picks the highest cipher in on the
>> list. If the client sends only NULL, then NULL is the only valid cipher.
>> OpenSSL has default list which includes weak ciphers (such as DES), so
>> using the default list is bad idea
>>
>
> this is not true at all and that's why you use tools like
> https://www.ssllabs.com/ssltest/ and SSLHonorCipherOrder as serveradmin
> for many years if you care about TLS at all
>
> also the default openssl cipherlist is not just random
>
> as you can see it prefers the ECDSA AES-GCM followed by the RSA AES-GCM
> and after the ECDHE it continues with other GCM ciphers na dthe DES/CBC
> stuff is at a place in the list which never is selected these days
>
> [harry@srv-rhsoft:~]$ openssl ciphers -v
> ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256)
> Mac=AEAD
> ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA  Enc=AESGCM(256)
> Mac=AEAD
> ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA
> Enc=CHACHA20/POLY1305(256) Mac=AEAD
> ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA
> Enc=CHACHA20/POLY1305(256) Mac=AEAD
> ECDHE-ECDSA-AES256-CCM8 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM8(256)
> Mac=AEAD
> ECDHE-ECDSA-AES256-CCM  TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM(256)
> Mac=AEAD
> ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128)
> Mac=AEAD
> ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA  Enc=AESGCM(128)
> Mac=AEAD
> ECDHE-ECDSA-AES128-CCM8 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM8(128)
> Mac=AEAD
> ECDHE-ECDSA-AES128-CCM  TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM(128)
> Mac=AEAD
> ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256)
> Mac=SHA384
> ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA  Enc=AES(256)
> Mac=SHA384
> ECDHE-ECDSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA
> Enc=Camellia(256) Mac=SHA384
> ECDHE-RSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=Camellia(256)
> Mac=SHA384
>
> ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128)
> Mac=SHA256
> ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA  Enc=AES(128)
> Mac=SHA256
> ECDHE-ECDSA-CAMELLIA128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA
> Enc=Camellia(128) Mac=SHA256
>
> ECDHE-RSA-CAMELLIA128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=Camellia(128)
> Mac=SHA256
>
> ECDHE-ECDSA-AES256-SHA  TLSv1 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1
> ECDHE-RSA-AES256-SHATLSv1 Kx=ECDH Au=RSA  Enc=AES(256)  Mac=SHA1
>
> ECDHE-ECDSA-AES128-SHA  TLSv1 Kx=ECDH Au=ECDSA Enc=AES(128)  Mac=SHA1
> ECDHE-RSA-AES128-SHATLSv1 Kx=ECDH Au=RSA  Enc=AES(128)  Mac=SHA1
> ECDHE-ECDSA-DES-CBC3-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=3DES(168) Mac=SHA1
> ECDHE-RSA-DES-CBC3-SHA  TLSv1 Kx=ECDH Au=RSA  Enc=3DES(168) Mac=SHA1
> AES256-GCM-SHA384   TLSv1.2 Kx=RSA  Au=RSA  Enc=AESGCM(256)
> Mac=AEAD
> AES256-CCM8 TLSv1.2 Kx=RSA  Au=RSA  Enc=AESCCM8(256)
> Mac=AEAD
> AES256-CCM  TLSv1.2 Kx=RSA  Au=RSA  Enc=AESCCM(256)
> Mac=AEAD
> AES128-GCM-SHA256   TLSv1.2 Kx=RSA  Au=RSA  Enc=AESGCM(128)
> Mac=AEAD
> AES128-CCM8 TLSv1.2 Kx=RSA  Au=RSA  Enc=AESCCM8(128)
> Mac=AEAD
> AES128-CCM  TLSv1.2 Kx=RSA  Au=RSA  Enc=AESCCM(128)
> Mac=AEAD
> AES256-SHA256   TLSv1.2 Kx=RSA  Au=RSA  Enc=AES(256)
> Mac=SHA256
> CAMELLIA256-SHA256  TLSv1.2 Kx=RSA  Au=RSA  Enc=Camellia(256)
> Mac=SHA256
> AES128-SHA256   TLSv1.2 Kx=RSA  Au=RSA  Enc=AES(128)
> Mac=SHA256
> CAMELLIA128-SHA256  TLSv1.2 Kx=RSA  Au=RSA  Enc=Camellia(128)
> Mac=SHA256
> AES256-SHA  SSLv3 Kx=RSA  Au=RSA  Enc=AES(256)  Mac=SHA1
> CAMELLIA256-SHA SSLv3 Kx=RSA  Au=RSA  Enc=Camellia(256)
> Mac=SHA1
> AES128-SHA  SSLv3 Kx=RSA  Au=RSA  Enc=AES(128)  Mac=SHA1
> CAMELLIA128-SHA SSLv3 Kx=RSA  Au=RSA  Enc=Camellia(128)
> Mac=SHA1
> DES-CBC3-SHASSLv3 Kx=RSA  Au=RSA  Enc=3DES(168) Mac=SHA1
> DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH   Au=DSS  Enc=AESGCM(256)
> Mac=AEAD
> DHE-

Re: [PHP-DEV] PHP 7.2.0 Released

[Walter Parker]

On Mon, Dec 4, 2017 at 2:21 PM, li...@rhsoft.net <li...@rhsoft.net> wrote:

>
>
> Am 04.12.2017 um 22:53 schrieb Walter Parker:
>
>> On Mon, Dec 4, 2017 at 1:43 PM, Niklas Keller <m...@kelunik.com> wrote:
>>
>>> and to be clear here:
>>>>
>>>> a client when connecting to a server configured like below has to
>>>> respect
>>>> the cipher order of the server while
>>>> https://www.ssllabs.com/ssltest/ exists for years to give dministrators
>>>> of the server some help and which clients are using which cipher
>>>>
>>>>
>>> Just minor nitpicking to get the facts right: A client does never respect
>>> the used cipher order of the server. A client offers a number of ciphers
>>> and the server chooses one of those, either based on its own order
>>> (preferred) or based on the client-preferred order.
>>>
>>> If you know other programs doing it better, research how they do it and
>>> propose a change to PHP please.
>>>
>>
> accepted, so PHP did only send a subset of the from openssl supported
> ciphers to the server not containing the modern ones
>
> That's good news. Given that openssl 1.1.0 only shipped late last year, I
>> fail to see how this has been an failure in PHP for many years for not
>> using a recent feature in openssl.
>> Looking at the sources for ab.c, it appears to do things like PHP. The
>> protocol level is hard coded to one value (SSL_METHOD
>> *SSLv23_method(void);)
>> There is a command line override (-Z protocol) that allows the protocol
>> selection to be changed to TLS1, TLS1.1, TLS1.2, or TLS1+TLS1.1+TLS1.2.
>>
>> Lists, could you please clarify what PHP should learn from how ab does
>> TLS?
>>
> as you can see in the ssllabs tests openssl 1.0.1 shipped years ago was
> able to use ECDHE/ECDSA with AES-GCM which is the recommended cipher, PHP
> until recent was only able to use "DHE-RSA-AES128-SHA", the first part is
> slow and the second part SHA1 is deprecated long ago for TLS
>
> PHP 7.1 even with openssl 1.1.x against MariaDB 10.2: ECDHE-RSA-AES128-SHA
>
> PHP 7.2 on the same environment: ECDHE-RSA-AES128-GCM-SHA256
> this was and is technically supported by openssl 1.0.x
>
> ssl-cipher = ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RS
> A-AES128-SHA"
>
> if you restrict mysqld to "ssl-cipher = ECDHE-RSA-AES128-GCM-SHA256"
> nothing before PHP 7.2.0 is able to connect at all
>
> at the same time "ab" which is a small 50 KB binary  supports ECDHE and
> AES-GCM ciphers for years and is also using openssl - it pretty sure gives
> a NULL as cipher to openssl which means openssl sends all it's supported
> ciphers to the server and the server then prefers the best one from his
> ordering due the handshake
>
> finally that means without touching the code around openssl from the
> moment on the openssl on the client side and the server supports and
> perefers a new cipher it will get used without touch "ab" and my question
> is why PHP is here completly differnt
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Oh, I see, this not about the actual change (the protocol version). This is
about when using PHP on the client side, it does not support all/enough of
the modern cipher suite list.

Now that we have identified the problem in question, this should help you
when you create your RFC to fix issues with the cipher suite list.

FYI, the client and server send lists of ciphers that they support to each
other, the server does an AND and picks the highest cipher in on the list.
If the client sends only NULL, then NULL is the only valid cipher. OpenSSL
has default list which includes weak ciphers (such as DES), so using the
default list is bad idea.

You keep using ab as your golden standard because it is small. I'd suggest
picking an application well known to be secure and not one based on the
fact that it is a small C program. I expect that ab gets the newer cipher
list by sending the large default list (which has both the strong items
with ECDHE & AES-GCM as well as DES and RC4). Server side, that would be a
major security issue.


Walter

-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] PHP 7.2.0 Released

[Walter Parker]

On Mon, Dec 4, 2017 at 1:43 PM, Niklas Keller  wrote:

> >
> > and to be clear here:
> >
> > a client when connecting to a server configured like below has to respect
> > the cipher order of the server while
> > https://www.ssllabs.com/ssltest/ exists for years to give dministrators
> > of the server some help and which clients are using which cipher
> >
>
> Just minor nitpicking to get the facts right: A client does never respect
> the used cipher order of the server. A client offers a number of ciphers
> and the server chooses one of those, either based on its own order
> (preferred) or based on the client-preferred order.
>
> If you know other programs doing it better, research how they do it and
> propose a change to PHP please.
>
> Regards, Niklas
>

That's good news. Given that openssl 1.1.0 only shipped late last year, I
fail to see how this has been an failure in PHP for many years for not
using a recent feature in openssl.
Looking at the sources for ab.c, it appears to do things like PHP. The
protocol level is hard coded to one value (SSL_METHOD
*SSLv23_method(void);)
There is a command line override (-Z protocol) that allows the protocol
selection to be changed to TLS1, TLS1.1, TLS1.2, or TLS1+TLS1.1+TLS1.2.

Lists, could you please clarify what PHP should learn from how ab does TLS?


Walter



-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] PHP 7.2.0 Released

[Walter Parker]

On Fri, Dec 1, 2017 at 3:35 PM, li...@rhsoft.net  wrote:

>
>
> Am 01.12.2017 um 22:49 schrieb Sara Golemon:
>
>> On Fri, Dec 1, 2017 at 11:52 AM, li...@rhsoft.net 
>> wrote:
>>
>>> yes and since nobody ever sould override the defaults in application code
>>> for obvious reasons that's the problem, you shouldn't mangle with openssl
>>> defaults in general and let openssl do the handshake which will end in
>>> the
>>> server side perferred cipher and so in the most secure
>>>
>>> what PHP does is making encryption weaker as it should be
>>>
>>> Um.  Did you look at the diff in question?
>>
>> The old default was tls 1.0 only, the new default is tls 1.0, 1.1, or 1.2.
>> The new default allows OpenSSL to negotiate for a preferred method
>> where it couldn't before.
>> The change literally does the opposite of what you're talking about
>>
>
> for *now* and then when TLS 1.3 is out, the openssl on the system supports
> TLS 1.3 PHP will hang on TLS1.2 as it did with TLS1.0?
>
> the main question is why does PHP need to to *anything* here instead hand
> the TLS handshake completly over to openssl? in that case even PHP5 could
> perfer TLS1.2 ciphers against a sevrer that orders them on top without
> touch any line of PHP's code
>
> "the opposite of what you're talking about" is plain wrong when you look
> at my first response
> _
>
> Am 30.11.2017 um 17:41 schrieb Hannes Magnusson:
>  >> - Improve TLS constants to sane values
>  >
>  > This worries me a lot. Last time someone thought it was a good
> idea they
>  > introduced security vulnerability for all apps that used them.
>
> that PHP now instead of ECDHE-RSA-AES128-SHA uses
> ECDHE-RSA-AES128-GCM-SHA256 for TLS connections (and before 7.1 with
> openssl 1.1 it was not able to use ECHDE at all) or that PHP don't let
> the crypto library alone at all?
>
> at least it got better with 7.2
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Lists, I fail to see how Sara was wrong and you are right.
In the old PHP, it was TLS 1.0
In the new PHP. it is TLS 1.2, TLS1.1, TLS1.3

When TLS1.3 comes out, old PHP will use only TLS1.0. <- This doesn't work
today for many sites
The new PHP will support TLS1.2, TLS 1.1, TLS 1.0 <- Still stronger that
the older version (required for many sites today)
When the openssl version that comes out to support the IETF final release
of TLS1.3 comes out in a few years, the openssl updates will be easier to
apply to the newest code base.

How many older PHP (5.X) systems will upgrade to (or even be able to
upgrade) to the newest openssl library?

As built right now, none of those would get TLS1.3 out of the box.

If you want the version selection moved completely to openssl, you should
write an RFC for that.

The current idea (where TLS1.3 is added to the list of defaults once the
software is release) vs an undefined system where it is handled magically
at a lower level doesn't appear to be more secure.


Walter


-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] RFC proposal: Provide support for XSLT 3.0, XPath 3.1, and XQuery 3.1

[Walter Parker]

On Wed, Oct 4, 2017 at 10:57 AM, Davey Shafik <da...@php.net> wrote:

> On Tue, Oct 3, 2017 at 1:29 PM, Walter Parker <walt...@gmail.com> wrote:
>
>> On Tue, Oct 3, 2017 at 7:51 AM, Dan Ackroyd <dan...@basereality.com>
>> wrote:
>>
>> > Hi O'Neil,
>> >
>> > On 3 October 2017 at 10:04, O'Neil Delpratt <on...@saxonica.com> wrote:
>> > > Hi,
>> > >
>> > > We are considering submitting an RFC along the following lines and
>> > welcome your comments:
>> > >
>> > > Enhancing the existing XSLTProcessor is not an option: it has fallen
>> too
>> > far behind for this to be viable.
>> >
>> > That's probably true.
>> >
>> > > Excelsior have a licensing scheme enabling the compiler to be used by
>> > open source
>> > > projects (see: https://www.excelsiorjet.com/free <
>> > https://www.excelsiorjet.com/free>).
>> >
>> > I don't have the multiple hours available now to fully read through
>> > and comprehend all the license information, however there are some red
>> > flags from my initial reading:
>> >
>> > > Instead, we now offer free personal licenses for that Edition to all
>> > prospects
>> > > who opt in when evaluating Excelsior JET.
>> > > 
>> > > Evaluate Excelsior JET and get a free Standard Edition license for
>> your
>> > personal use:
>> > > ...
>> > > If you do not wish to receive a free license, you may skip the
>> > registration and
>> > > download Excelsior JET Evaluation Packages anonymously.
>> >
>> > Having to register and opt in to obtain a license, seems like a problem.
>> >
>> > > Caveat #1: The Excelsior JET Runtime cannot be used in embedded
>> systems
>> > > due to a licensing restriction.
>> >
>> > That seems like a problem.
>> >
>> > > Caveat #2: The Standard Edition is essentially an entry‑level variant
>> of
>> > > the product, which means that: It is not available for OS X.
>> >
>> > That seems like a problem.
>> >
>> > With regards to the more technical aspects of the proposal.
>> >
>> > Can you say how much bigger including all of the relevant libraries
>> > would make the PHP executable? Some people have already expressed
>> > concern at how large the default PHP executable has become.
>> >
>> > What I would suggest is, if you think the license issues can be
>> > resolved, to apply for a PECL account at http://pecl.php.net/ and
>> > start having people to start using the extension through there.
>> >
>> > Having a quick look at the extension source code, I get the impression
>> > that having more people use it could result in lots of small
>> > refinements to the implementation that should be done before the
>> > extension was ready to bring into PHP core.
>> >
>> > cheers
>> > Dan
>> > Ack
>> >
>> > --
>> > PHP Internals - PHP Runtime Development Mailing List
>> > To unsubscribe, visit: http://www.php.net/unsub.php
>> >
>> >
>> From the ExcelsiorJet FAQ Page:
>> Is the Excelsior JET license GPL-compatible?
>> <https://www.excelsiorjet.com/free#>
>>
>> Unfortunately, no. Excelsior JET includes the Java SE API source code
>> licensed from Oracle under OCSL Commercial Use license, which is not
>> GPL-compatible. So even releasing our own code under the GPL won't help.
>> LGPL is fine however.
>>
>> We suggest you to release the natively compiled binary under a different
>> license, pointing out that the source code is available under the GPL. You
>> would however need the consent of all contributors.
>> Does new code to the core have to be GPL-compatible? Or has it changed to
>> LGPL. This may be a showstopper.
>>
>> Also, the fact it only generates 32-bit code may also be a non starter, as
>> lots of Linux & BSD systems are now running 64-bit as the default/common
>> install.
>>
>>
>> Walter
>>
>
> You seem to be mistaken in thinking the PHP project is GPL licensed. It is
> in fact licensed under the PHP License[1], and AFAIK does not allow
> GPL-licensed in core (LGPL is fine)…
>
> [1] http://php.net/license/3_0.txt
>

Sorry, my mistake. I didn't notice when PHP changed from GPL style to BSD
style.

I withdraw my comments on the the GPL issue.


Walter


-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] RFC proposal: Provide support for XSLT 3.0, XPath 3.1, and XQuery 3.1

[Walter Parker]

On Tue, Oct 3, 2017 at 7:51 AM, Dan Ackroyd  wrote:

> Hi O'Neil,
>
> On 3 October 2017 at 10:04, O'Neil Delpratt  wrote:
> > Hi,
> >
> > We are considering submitting an RFC along the following lines and
> welcome your comments:
> >
> > Enhancing the existing XSLTProcessor is not an option: it has fallen too
> far behind for this to be viable.
>
> That's probably true.
>
> > Excelsior have a licensing scheme enabling the compiler to be used by
> open source
> > projects (see: https://www.excelsiorjet.com/free <
> https://www.excelsiorjet.com/free>).
>
> I don't have the multiple hours available now to fully read through
> and comprehend all the license information, however there are some red
> flags from my initial reading:
>
> > Instead, we now offer free personal licenses for that Edition to all
> prospects
> > who opt in when evaluating Excelsior JET.
> > 
> > Evaluate Excelsior JET and get a free Standard Edition license for your
> personal use:
> > ...
> > If you do not wish to receive a free license, you may skip the
> registration and
> > download Excelsior JET Evaluation Packages anonymously.
>
> Having to register and opt in to obtain a license, seems like a problem.
>
> > Caveat #1: The Excelsior JET Runtime cannot be used in embedded systems
> > due to a licensing restriction.
>
> That seems like a problem.
>
> > Caveat #2: The Standard Edition is essentially an entry‑level variant of
> > the product, which means that: It is not available for OS X.
>
> That seems like a problem.
>
> With regards to the more technical aspects of the proposal.
>
> Can you say how much bigger including all of the relevant libraries
> would make the PHP executable? Some people have already expressed
> concern at how large the default PHP executable has become.
>
> What I would suggest is, if you think the license issues can be
> resolved, to apply for a PECL account at http://pecl.php.net/ and
> start having people to start using the extension through there.
>
> Having a quick look at the extension source code, I get the impression
> that having more people use it could result in lots of small
> refinements to the implementation that should be done before the
> extension was ready to bring into PHP core.
>
> cheers
> Dan
> Ack
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>From the ExcelsiorJet FAQ Page:
Is the Excelsior JET license GPL-compatible?


Unfortunately, no. Excelsior JET includes the Java SE API source code
licensed from Oracle under OCSL Commercial Use license, which is not
GPL-compatible. So even releasing our own code under the GPL won't help.
LGPL is fine however.

We suggest you to release the natively compiled binary under a different
license, pointing out that the source code is available under the GPL. You
would however need the consent of all contributors.
Does new code to the core have to be GPL-compatible? Or has it changed to
LGPL. This may be a showstopper.

Also, the fact it only generates 32-bit code may also be a non starter, as
lots of Linux & BSD systems are now running 64-bit as the default/common
install.


Walter

-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] array coalesce operator concept

[Walter Parker]

On Thu, Jul 13, 2017 at 2:55 AM, Tony Marston 
wrote:

> "David Rodrigues"  wrote in message news:CAEsg9X2ECG62i7Z_Nu11kqr7
> yvbkmucd3mxgt78ulampfx-...@mail.gmail.com...
>
>>
>> The idea is good, but I don't know if it is more clear than an 'if()'
>>
>
> I think that this proposal is totally ridiculous and should be shot down
> in flames. My reasoning is as follows:
>
> 1) There should be a rule that anything which can be achieved with 5 lines
> or less in userland code should be automatically excluded from becoming a
> change to the language. The cost of changing the language in order to get
> around the laziness of a small number of users versus the "benefit" of
> making the language more complicated for the rest of us, as well as adding
> to the maintenance burden is simply not worth it.
>
> 2) Proposals such as this violate the first rule of good programming which
> is to provide code which is readable and therefore understandable by
> others, and therefore maintainable. I don't know about you, but I find it
> much easier to read words than symbols. The idea that the code "if
> (is_array($foo))" is too verbose and should be replaced with a shorthand
> symbol is just too ridiculous for word. If any more of these shortcuts is
> implemented then I'm afraid that code will look too much like a bunch of
> hieroglyphics and become far less readable.
>
> Just my 2 cents worth.
>
> --
> Tony Marston
>
>
> Em 11 de jul de 2017 12:15 PM, "Mark Shust"  escreveu:
>>
>> Hello,
>>>
>>> I wanted to garnish feedback on a RFC proposal. This is just a concept at
>>> this point, and is inspired by the null coalesce operator.
>>>
>>> Code will error if a non-array value is passed through a looping feature.
>>> For example, this code:
>>>
>>> >>
>>> $foo = "abc";
>>>
>>> foreach ($foo as $bar) {
>>>
>>>   echo $bar;
>>>
>>> }
>>>
>>>
>>> will result in the error:
>>>
>>> PHP Warning:  Invalid argument supplied for foreach() in test.php on
>>> line 3
>>>
>>>
>>> To prevent this, the logical solution is to wrap this in an is_array
>>> check:
>>>
>>> >>
>>> $foo = "abc";
>>>
>>> if (is_array($foo)) {
>>>
>>>   foreach ($foo as $bar) {
>>>
>>> echo $bar;
>>>
>>>   }
>>>
>>> }
>>>
>>>
>>> This code runs successfully and does not error out. For a syntactic
>>> sugar/improvement, this can be shorthand for executing the loop instead
>>> of
>>> wrapping the block within an is_array check:
>>>
>>>
>>> >>
>>> $foo = "abc";
>>>
>>> foreach (??$foo as $bar) {
>>>
>>>   echo $bar;
>>>
>>> }
>>>
>>>
>>> Let me know your thoughts.
>>>
>>>
>>> Cheers,
>>> Mark
>>>
>>>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

The more I think about this, the more I think that the throwing a warning
when the variable is not an array is the proper thing to do. The cost in
missed mistakes is much larger than the tiny savings in code that some
people would get.


Walter
-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] Directory separators on Windows

[Walter Parker]

On Thu, Mar 30, 2017 at 8:21 AM, Sara Golemon  wrote:

> My first thought is UNC paths.  On windows a file server share is
> denoted by \\host\share . if you combine that with relative paths
> produced from PHP, you end up in the dubious situation of
> "\\host\share/path/to/file" <--- wat?
>
> Overall, it smells of magic.
>
> -Sara
>
> On Thu, Mar 30, 2017 at 8:25 AM, Rasmus Schultz 
> wrote:
> > Today, I ran into a very hard-to-debug problem, in which paths (to SQL
> > files, in a database migration script) were kept in a map, persisted to a
> > JSON file, and this file was moved from a Windows to a Linux file-system
> -
> > because the paths on the Linux system had forward slashes, the files
> > appeared to be missing from the map.
> >
> > Related questions are very commonly asked by Windows users, indicating
> that
> > this is a common problem:
> >
> > http://stackoverflow.com/questions/14743548/php-on-
> windows-path-comes-up-with-backward-slash
> > http://stackoverflow.com/questions/5642785/php-a-good-
> way-to-universalize-paths-across-oss-slash-directions
> > http://stackoverflow.com/questions/6510468/is-there-a-
> way-to-force-php-on-windows-to-provide-paths-with-forward-slashes
> >
> > The answers that are usually given (use DIRECTORY_SEPARATOR, use
> > str_replace() etc.) is that by default you automatically get
> cross-platform
> > inconsistencies, and the workarounds end up complicating code everywhere,
> > and sometimes lead to other (sometimes worse) portability problems.
> >
> > The problem is worsened by functions like glob() and the SPL
> directory/file
> > traversal objects also producing inconsistent results.
> >
> > Returning backslashes on Windows seems rather unnecessary in the first
> > place, since forward slashes work just fine?
> >
> > Might I suggest changing this behavior, such that file-system paths are
> > consistently returned with a forward slash?
> >
> > Though this is more likely to fix rather than create issues, this could
> be
> > a breaking change in some cases, so there should probably be an INI
> setting
> > that enables the old behavior.
> >
> > Thoughts?
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

UNC pathing also works with forward slashes. For example, in powershell the
following is valid and works if your host is named UNC1 and you have admin
rights to the server.

//UNC1/C$/


-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] Re: Not autoloading functions

[Walter Parker]

On Thu, Jan 26, 2017 at 12:23 PM, Rasmus Schultz  wrote:

> > if you choose to use static methods instead of functions
>
> It's not a choice - functions are practically useless in a Composer
> context, and most everything PHP is now Composer packages.
>
> Why are functions useless when using Composer? Is it because functions
can't be autoloaded?
Is this about getting functions to load without having to stick them in
classes that can be autoloaded?



> > why do you need this special syntax for calling them then?
>
> Yeah, but the same logic applies to namespaces and classes:
>
> If you choose to use namespaces, why do you need aliases for classes?
>
> Strictly speaking, you don't - but it would be really ugly and
> inconvenient. Forcing you to qualify a namespace or the parent class of a
> function repeatedly is just noise, same as qualifying the namespace before
> every class or interface-reference.
>
> Agreed, it has no functional value, but neither does namespace-aliasing.
>
> Both have a considerable organizational benefit though: the ability to list
> all your class, interface and function imports at the top of a file.
>
> To me, that's valuable.
>
> Either way, guys, here's a preliminary RFC:
>
> https://wiki.php.net/rfc/use-static-function
>
> While trying to describe this, I have to say, this doesn't appear to be the
> slam-dunk it seemed to be - you can read the details on that page, but
> given the two alternative approaches described on this page, it seems this
> feature is likely to create just as many problems and WTF as the
> auto-loading RFC.
>
> I'm afraid one isn't much better or worse than the other in that sense
> really...
>
> Oh well :-/
>
>
> On Thu, Jan 26, 2017 at 6:50 PM, Niklas Keller  wrote:
>
> > > The problem with stop-gap measures is they become entrenched, and the
> >> proper solution doesn't get implemented
> >>
> >> This would be my general point of view - unfortunately, functions are
> >> essentially useless at present, in a world with Composer, unless you're
> >> willing to preload all functions from all packages up-front.
> >>
> >> The only suggested solutions I've heard for the name resolution issue
> with
> >> function autoloading frankly are all horrible - much worse than this
> >> simple
> >> alternative.
> >>
> >> Add to that the fact that likely 90% of all functions in the wild (at
> >> least
> >> in Composer packages) are currently implemented as public static
> >> functions,
> >> and in my opinion, this is starting to sound less like a stop-gap and
> more
> >> like a simple solution to a problem we've been solving with a stop-gap
> >> for,
> >> oh, 10 years or so...
> >
> >
> > Again, if you choose to use static methods instead of functions, why do
> > you need this special syntax for calling them then?
> >
> > Regards, Niklas
> >
>



-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

[PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

[Walter Parker]

>
> It is NOT insulting to say that people who still insist on using command
> line tools are living in the past for the simple reason that the command
> line interface was replaced with the GUI when the Windows OS was released
> in the 1990s. That is 25 years ago. Is that in the past or what? Without a
> GUI Windows would not be the success it is today.
>
> --
> Tony Marston
>
>
Well, many would take that as a bit insulting, but if it isn't then I'd
free to comment that your statements about command lines are parochial,
uninformed, ignorant, and indicative of small scale development mindset
that has never seen large scale & repeatable development that works well.
When Windows joined the Web Server market in the 90's, the administration
and deployment of web sites took a step backwards from the viewpoint of
many ISPs. Items that had been automated now had to be done by hand because
the GUI was the only way to setup/admin websites. It took year for
Microsoft to get even half way there.

FYI, Unix actually had GUIs before Windows. GUis are older than Windows,
DOS, PHP, Linux, does that make people using them "living in the past?"
 The GUI complements the command line in Unix/MacOS, it is WIndows/DOS were
the command line was done so poorly for decades that causes PC users to
have lost sight to the value of the command line. But this a common item
found in the Unix world, those that don't understand are blind to the power
that it has. Microsoft was this way for decades, until it recovered the
clue 5-10 years ago and started making automation thought command line
applications a thing again with Powershell.

At some point, you might thing about breaking out of the narrow
shell/straight-jacket that a GUI only existence imposes on people and look
at the power and freedom that a mixed approach allows. Or not, as I'm sure
your customers/boss don't care about the extra costs that a GUI can impose
as are likely as blind to costs of a GUI only world as well.

My opinion is that you are a GUI only user that is scared of the command
line and is worried that your simplified GUI tool will stop working as the
rest of the group continues to race past you using a mix of GUI and command
line tools. If this is the case, learning a bit about the command line
tools will be you best insurance against issues the the GUI tools breaking.


Walter


-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] Re: [PHP] feature request : gzip caching

[Walter Parker]

On Sat, Aug 27, 2016 at 7:56 PM, Rene Veerman <
rene.veerman.netherla...@gmail.com> wrote:

> noted, and sorry about confusing it, but can we rest this discussion here?
> i dont wanna clog up the thread any further..
>
>
>
Before you go, two observations:

First, your website doesn't actually appear to work in a modern version of
Chrome. Should it?
Second, if you want a binding EULA on your website, you might want to check
with an IP lawyer.

Putting a EULA in the page source comments will not meet the conditions of
contract law in most countries. To anybody knowledgeable about the field,
your EULA reflects a TV show level of understanding of the law.


Walter

-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] New escaped output operator

[Walter Parker]

Good, then we do agree, as what I said was what I DID NOT want to see in
the documentation.

This should be documented as shortcut for . It should be further pointed out that while this will be useful in
catching many XSS and other HTML issues, it will not catch all of them, so
care and attention to proper data hygiene is still required.


Walter

On Sun, Jun 19, 2016 at 8:22 PM, Михаил Востриков <
michael.vostri...@gmail.com> wrote:

> > "Use ' outputting HTML that was stored in a DB."
> I don't think this is a good phrase for documentation. This form should be
> considered exactly as htmlspecialchars, with taking into account any
> language and encoding-specific issues, and this should be pointed in
> documentation. This is a shorcut for often operation, like '??' for isset()
> check. And it can really improve security, not in 90% but about 99.%
> cases.
>
> 2016-06-20 4:41 GMT+05:00 Walter Parker <walt...@gmail.com>:
>
>>
>>>
>>> > where getting it 90% correct is worse that not doing anything at all.
>>> > Things like this will cause people to be blindsided when the uncaught
>>> escapes
>>> > cause the next major security problem.
>>>
>>> Why do you think so? What real problems can happen if there will be a
>>> short operator for htmlspecialchars()?
>>>
>>> What could happen is this getting sold/documented as a general purpose
>> security feature:
>> "Use '> outputting HTML that was stored in a DB."  What it solves is a subset,
>> which is escaping characters stored in a data that have special meanings to
>> HTML. My concern is that the remain security issues might get overlooked or
>> ignored because '> htmlspecialchars, UTF-8 and certain language-specific characters (non
>> English). There were also issues with quotes in the past.
>>
>>
>> Walter
>>
>
>


-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] New escaped output operator

[Walter Parker]

>
>
>
> > where getting it 90% correct is worse that not doing anything at all.
> > Things like this will cause people to be blindsided when the uncaught
> escapes
> > cause the next major security problem.
>
> Why do you think so? What real problems can happen if there will be a
> short operator for htmlspecialchars()?
>
> What could happen is this getting sold/documented as a general purpose
security feature:
"Use '

Re: [PHP-DEV] New escaped output operator

[Walter Parker]

>From your story Scott, it looks like the failure was bad input filtering,
not input filtering in general. If sites are really trying to be secure,
they should follow both Lester's and your ideas and filter on input and
escape on output.

Given your second link the better suggestion is to stop taking raw HTML.
Assuming user generated HTML is ever safe to re-render in an output page
has been a bad idea for years. Ebay/paypal once thought that stripping all
letters and numbers from JavaScript was enough to make it safe, it wasn't.
Somebody used just things like (){}[]=+ to build functional attack scripts.

While a simple method of output escaping seems like a good idea, I agree
with the others that point out that is one of those security systems where
getting it 90% correct is worse that not doing anything at all. Things like
this will cause people to be blindsided when the uncaught escapes cause the
next major security problem.


Walter

On Sun, Jun 19, 2016 at 10:28 AM, Scott Arciszewski 
wrote:

> On Sun, Jun 19, 2016 at 1:14 PM, Lester Caine  wrote:
>
> > On 19/06/16 10:01, Marco Pivetta wrote:
> > > This basically means that you lack basic understanding of how escaping
> > and
> > > user input are to be handled.
> > > Most apps out there about getting a bunch of text from the user, then
> > > rendering it somewhere else in the app.
> > > Cleaning user input just leads to frustration and a big mess in most
> > > scenarios, which is why we're all talking about escaping output
> instead.
> > > This is not "cleaning" either, it's escaping, which is a
> non-destructive
> > > and reversible operation (which is why it works so well).
> >
> > Well we have to disagree ... simply expecting htmlspecialchars() to fix
> > all your problems without proper handling of the input text is 'the big
> > mess' and there is NO need to simply slap htmlspecialchars() onto
> > properly built data so the idea that  > totally pointless!
> >
> > --
> > Lester Caine - G8HFL
> > -
> > Contact - http://lsces.co.uk/wiki/?page=contact
> > L.S.Caine Electronic Services - http://lsces.co.uk
> > EnquirySolve - http://enquirysolve.com/
> > Model Engineers Digital Workshop - http://medw.co.uk
> > Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> ​Let me tell you a story.
>
> Once upon a time, WordPress decided to escape user input to protect against
> XSS attacks. Then this happened: https://klikki.fi/adv/wordpress2.html
> (Stored XSS via MySQL Column Truncation vulnerability.)
>
> Escaping against XSS attacks should happen on output, not on input. Dead
> stop.
>
> You MAY cache the escaped output for performance gains, but keep the
> unescaped data in the database in case you need to adjust your escaping
> strategy without mangling existing data.
>
> Further reading:
>
> https://paragonie.com/blog/2015/06/preventing-xss-vulnerabilities-in-php-everything-you-need-know
> ​
>
> Scott Arciszewski
> Chief Development Officer
> Paragon Initiative Enterprises ​
>



-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] New escaped output operator

[Walter Parker]

Thomas, are you actually reading and understanding what the others are
saying?

You seem to be answering questions that have not been asked or giving the
simple, easy and wrong answer.


Walter

On Fri, Jun 17, 2016 at 1:37 PM, Thomas Bley  wrote:

> using the default encoding from php.ini's default_charset should be no
> problem, htmlspecialchars() already does it if the encoding parameter is
> not provided.
>
> Regards
> Thomas
>
> Niklas Keller wrote on 17.06.2016 22:31:
>
> > Hi,
> >
> > the issue is that things have to be escaped dependent on the context. If
> > you are in a HTML context you need different escaping than you need in a
> > CSS or JS block. The escaping should also be aware of the content
> encoding.
> > All that makes it difficult for PHP to directly support such an operator.
> >
> > You can always alias "e" or something like that to be your default escape
> > function.
> >
> > Regards, Niklas
> >
> > Михаил Востриков  schrieb am Fr.,
> > 17. Juni
> > 2016, 21:29:
> >
> >> Hello. I was thinking about a presence of escaped output operator in PHP
> >> and found this feature request: https://bugs.php.net/bug.php?id=62574.
> I
> >> think this is quite necessary feature. There are a lot of projects
> which is
> >> written without templating engine, and there are frameworks without
> >> built-in templating engine by default. All this projects require to
> write
> >> the code. Usually it is rather simple to switch to new version of
> language,
> >> but it is almost impossible to switch many and many templates on a
> >> templating engine.
> >>
> >> Most of output code is an output of properties of database entities, and
> >> only in some cases it's needed to concatenate HTML into string and then
> >> print it with unescaped output. Escaped output operator can be useful.
> Also
> >> we output data not into the void and not into simple text file, but into
> >> HTML-document which has a certain format (markup). Also this is logical
> -
> >> to have both forms, escaped and unescaped.
> >>
> >> I want to suggest the operator "", which will automatically
> wrap
> >> output in htmlspecialchars(). It is mentioned in the feature request
> above.
> >> It is quite easy to type, and there is a small possibility to write " >> ?>" instead.
> >>
> >> In PHP 7 there are new operators and other changes. I think, new echo
> >> operator also can be added. I can implement it myself.
> >>
> >
>
>
> --
> 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

Re: [PHP-DEV] How to get trace of all database queries executed by php

[Walter Parker]

On Fri, May 6, 2016 at 4:34 PM, Raja Kulasekaran  wrote:

> Hi,
>
> Sorry If I am asking this question in irrelevent forum.
> Please suggest me the point of direction if not.
>
> I have encrypted php Application codebase which I may or may not have
> access.
>
> So, I would like to know how the application behaving / profiling Database
> queries through the .so or .dll level .
>
> Is there any php extension available which help me out to give the
> statistics of
> all the queries execution details ?
>
> Thanks,
> Raja K
>


This is not really the right list.
However, you might look at turning on SQL query logging/statistics on the
DB server side. The DB should be able to give you stats and feel for the
query profiles. This would be a lot less work than adding shims to the
plugins.


Walter
-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] [RFC Discussion] Typed Properties

[Walter Parker]

On Friday, March 18, 2016, Larry Garfield  wrote:

> On 03/18/2016 03:49 PM, Fleshgrinder wrote:
>
>> First a general note on the complete nullability first: It is not up to
>> us as language designers to decide whether it is good practice to use
>> nullable properties or not. It is supported by many systems since ages
>> (e.g. SQL where nullable fields are also not recommended but heck they
>> are useful) and it is common practice in PHP. Hence, there must be
>> support for it. That does not mean that it is endorsed in any way by us,
>> it is just there for people who need it for the same reasons they needed
>> it in the past 20 or so years.
>>
>
> At the risk of a small tangent, I cannot agree at all here.  The whole
> point of language design is to make decisions regarding what "good
> practices" to encourage, enforce, or disallow.  Some languages disallow
> mutable variables (despite them being useful).  Some languages disallow
> global variables (despite them being occasionally useful).  Some languages
> disallow NULLs (despite them having use cases in many languages).  Those
> are all viable and reasonable decisions for a language designer to make in
> various circumstances; to say that it's "not up to us as language
> designers" to make such decisions is to abdicate our responsibility as
> language designers.
>
> There may well be good arguments to allow property nullability. There's
> also good arguments against it.  We'll decide one way or another.  But "we
> shouldn't take a position at all" is worse than taking a position, because
> that implicitly does take a position (allowing it), while pretending that
> we didn't.  Basically it means lying to ourselves about it, which is never
> the right answer.
>
> Design is about making deliberate, informed decisions.  Let's make a
> deliberate, informed decision.
>
> To help with the informed part, can anyone speak to how other languages
> handle null-typed properties?  I believe Java allows everything to be NULL
> (which sucks), but I'm not sure about other modern languages.  Can anyone
> speak to that?  (I'd be particularly interested in Python, Go, and Rust,
> but any language you can speak to definitively would be valuable to know
> about.  Javascript and Ruby are, AFAIK, insufficiently typed for the
> question to apply.)
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> C A Horte, the famous computer scientist, calls the introduction of nulls
into his type system (like how Java did it decades later) to be his Billion
dollar mistake. He did it for the mathematical elegance and didn't foresee
all of the null errors that would come. Nulls sound great in theory, in
practice they can be trouble.


Walter


-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal

[Walter Parker]

>
>
> That we should definitely avoid. I do not consider the *var* keyword
> being a discussion about coding style preferences---this decision was
> already made in PHP 5! The *public* keyword was introduced and it
> superseded the *var* keyword including an E_STRICT error. Hence, this
> discussion is not about whether this was good, correct, or whatever
> decision: it is already done! This is about clean-up of the old unwanted
> way of doing it and by now maybe even a discussion about clean-up in
> general.
>
> TL;DR Clean-up is important but there must be an easy to follow
> migration path and enough time. We have both here, still +1
>
> --
> Richard "Fleshgrinder" Fussenegger
>
>
If this cleanup is such a good idea, why did it take 12 years for someone
to suggest it. Why wasn't var removed years ago? What is the sudden urgency
to remove it now?

Have programmer become more confused? This alias does not appear to have
been an issue for the last 12 years.

What has changed? Are we on a cusp of the paradigm change (the type that
happens when the old folk have gone away, so the younger folk can get their
way because they now have the numbers)?


Walter

-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal

[Walter Parker]

On Mon, Mar 7, 2016 at 4:27 AM,  wrote:

> > Change for the sake of change is bad, no argument there. Change for the
>
> > sake of progress is not and totally normal.
>
>
>
> Can you please specify what kind of progress do see in the `var` keyword
> removal? I see only a BC break.
>
>
>
>
> Very best regards,
> Kubis Pandian-Fowler
>
>
>
>
>
>
> Od: Fleshgrinder
> Odoslané: ‎štvrtok‎, ‎3‎. ‎marca‎ ‎2016 ‎22‎:‎23
> Komu: internals@lists.php.net
>
>
>
>
>
> On 3/3/2016 10:34 AM, Tony Marston wrote:
> > If you want to avoid such confusion over alias names then surely that
> > would be an argument against introducing aliases in the first place. In
> > this case the short array syntax would never have been introduced as the
> > (only slightly longer) long array syntax had already existed since day
> #1.
>
> No, that is not what one should conclude from it. Short array syntax was
> added by popular demand and hence for a very good reason. The fact that
> there are no plans regarding the old syntax and thus keeping the
> duplication indefinitely is the actual problem.
>
> Change for the sake of change is bad, no argument there. Change for the
> sake of progress is not and totally normal.
>
> On 3/3/2016 2:04 PM, Rowan Collins wrote:
> > I'm not sure what Lester had in mind, but in many cases legacy code
> > which used "var" should actually be updated to mark properties as
> > "protected" or "private" instead. Such properties are public only
> > because PHP4 had no other visibility, and explicitly marking them all
> > "public" simply masks the real job, which is assessing which
> > visibility each property should have.
> >
> > It occurs to me that if I saw "var", I would not think "that should be
> > public", but "that needs assessing for visibility". I do the same with
> > legacy code where methods are written as "function foo()" rather than
> > "public function foo()" - I check whether it should actually be
> > public, and also in that case whether it should be static.
>
> It seems as if this is not the issue for the people who are against
> removing the "var" keyword from PHP 8. They simply do not want to change
> their scripts at all. The described procedure is truly time consuming
> since it involves to check all usages everywhere as well. Simply
> changing from "var" or "public" to any other visibility is a brutal change.
>
> --
> Richard "Fleshgrinder" Fussenegger
>


It is a disagreement over language design, the Python way vs the Perl way.
The Perl way says: There is more than one way to do things
The Python way says: There is one correct way to do things. Other methods
should be removed.

There is a desire among some PHP people to have the language be more like
the Python mindset.

-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal

[Walter Parker]

On Sat, Mar 5, 2016 at 7:00 AM, Fleshgrinder  wrote:

> On 3/5/2016 2:33 PM, Lester Caine wrote:
> > On 05/03/16 11:26, Fleshgrinder wrote:
> >> PHP being a mess is still one of the most quoted arguments against PHP!
> >>
>  Only if it results in an actual and measurable improvement. Changes
> for
>  "purity" or "consistency" do NOT fall into this category.
> >
> >> This is your believe and you know that many people disagrees with you on
> >> this; you just commented on the "[RFC] Deprecations for PHP 7.1" thread
> >> and we have much more of those RFCs and threads.
> >
> > There are a number of schools of thought, one will say 'You don't have
> > to update your perfectly functional code', just use a version of PHP
> > that it will run on, so over 40% of users are 'stuck' with Php5.2/3
> > either because they don't have the support to change or the need to
> > change. Much of that code was written by people who are no longer
> > involved or interested and so unless others pick up the baton, there
> > will be little progress. I still run 5.2 on sites simply because it's
> > simply uneconomic to change them.
> >
> > Now moving code forward, handling every warning and simply keeping code
> > running from version to version, one hits the problem that sites that
> > are reliant on older versions of PHP can't easily be run with newer
> > versions. I've managed to build a way around that problem by now running
> > php-fpm/nginx which allows me to actually run the same code across
> > multiple versions of PHP. But one has to be very careful about just what
> > is changed at each step, so in my book, unless there is some good
> > security reason to stop something working then it should remain for BC
> > reasons.
> >
> > Others are of the opinion that all current PHP code is a mess and my
> > reaction to that is ... well use a different language then! ...
> > expecting the vast majority of users to rename every function ( on of
> > the proposals for PHP7 ) or switch to a strictly typed method of working
> > is simply not going to happen, so I have no problem with people adding
> > new extensions which allow these different sytles of working as long as
> > the underlying procedural style of working is maintained in as BC a way
> > as possible, so things like 'var' and a number of the 7.1 deprecation
> > proposals simply destroy BC with little gain to a pure OO based version
> > of PHP anyway.
> >
> > I actually wonder what would have happened if there had been a stable
> > fork of PHP5.2 maintained, with security fixes, rather than the
> > piecemeal security fixes that are currently being applied on those
> > services that maintain PHP5.2/3 currently.
>
> But then again, we are talking about removal and real BC in 6 to 9 years
> and support for code that is already roughly 11 years old; so up to 20
> years old then. I guess nobody would ever consider rewriting that code
> and instead simply write it anew.
>
> --
> Richard "Fleshgrinder" Fussenegger
>
>
For software written for other people and for projects that don't have
ongoing tech staffs that do tech debt maintenance, they would like to keep
old, working code running. Telling them that they must spend money to
update the software so that the language can look cleaning is often a hard
sell.

 Outside of the PHP world, there are code bases that are 20-30 years old.
See Linux, Apache HTTPD, in-house software at many corporations.

One of the lessons of the Y2K rollover was that software choices made in
the 50-60's (and in some cases the actual software itself) was felt 40-50
years later because the software wasn't rewritten anew every 10-20 years.
Some companies treat software like capital assets and not as expendables.
They want it to last like a house and not be be replaced every 5-10 years
(like many cars).


Walter

-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal

[Walter Parker]

On Fri, Feb 19, 2016 at 1:10 AM, Tony Marston <tonymars...@hotmail.com>
wrote:

> "Walter Parker"  wrote in message
> news:CAMPTd_AHyV2d0_Saq=kpvhdzkkcmgkxav8tnt4hk9sdngkc...@mail.gmail.com...
>
>>
>> On Thu, Feb 18, 2016 at 11:30 AM, Sebastian Bergmann <sebast...@php.net>
>> wrote:
>>
>> On 02/18/2016 02:10 PM, Colin O'Dell wrote:
>>>
>>> I'd like to propose an RFC to deprecate and eventually remove the "var"
>>>> keyword.
>>>>
>>>>
>>>  +1
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>>> What are your reasons for this proposal?
>>
>> I can think of multiple reasons why this might not be a good idea, but the
>> only reason that pops to mind for getting rid of it is to make PHP work
>> like a different style of language.
>>
>>
>> Walter
>>
>
> Your reason "make PHP work like a different style of language" is
> meaningless. The removal of the "var" keyword does not change any
> functionality.
>
> --
> Tony Marston
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I've been doing too much C# lately, mixing up the definitions of var (C#
now uses var very frequently in coding).

-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal

[Walter Parker]

On Thu, Feb 18, 2016 at 11:30 AM, Sebastian Bergmann 
wrote:

> On 02/18/2016 02:10 PM, Colin O'Dell wrote:
>
>> I'd like to propose an RFC to deprecate and eventually remove the "var"
>> keyword.
>>
>
>  +1
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
What are your reasons for this proposal?

I can think of multiple reasons why this might not be a good idea, but the
only reason that pops to mind for getting rid of it is to make PHP work
like a different style of language.


Walter

-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] is_digits() and digits type

[Walter Parker]

In C, the int data type is defined as being at least 16 bits in size. Long
is defined as being at least 32 bits and long long is defined as being at
least 64 bits in size. The standard further recommends that the size of int
be the most natural and efficient for the processor (i.e. 16 on 16 bit
processors, 32 on 32 bit processors, 64 on 64 bit processors). The C99
standard added standard types for integers that had defined sizes (the
8bit, 16 bit, 32 bit and 64 bit integer types). In Java, the sizes are
fixed, but I think you missed my point as there are multiple integer types
not that they change sizes.

PHP was written to use the first suggestion (integers being the natural
data size of 32 or 64 bit). To keep PHP simple, there is a desire to not
introduce several different integer sizes in PHP. Your right, this does
make it harder for people that want to use 64 bit integers on 32 bit
systems as 64 bit integers. For those people, they will have to use strings
or bignum. Given the lack of desire for this addition, the relatively small
number of PHP developers, and the idea that this is a legacy issue, I'd be
surprised if you. could get support for this.

Adding a numeric pseudo type will not fix abuse, it will only change the
abuse. I don't think it is worth the effort. I also think it might a
slippery slope to lots of other pseudo types and other half ideas that will
add complexity to the language without much in the way of benefit.

The mixing of types, casts and validations can cause problems. I don't see
how adding pseudo types will actually fix this as this appears to a
validation problem and not a typing problem.


On Thu, May 14, 2015 at 12:16 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 Hi Walter,

 On Tue, May 12, 2015 at 11:25 AM, Walter Parker walt...@gmail.com wrote:

 You know, given how worried you seem to be about this issue, could you
 booby trap your so that if the developers use the wrong type (int vs.
 string) the program throws fatal errors with nasty error messages that
 explain how much trouble the developer is in at the userland code level?

 While I like the of protecting idiot developers from themselves, I'm
 still not sure that this isn't a half solutions that just hide the pieces
 of the problem that it doesn't solve.

 I don't think we can solve the problem of developers not writing code
 correctly or QA would mostly be out of job (instead of being a growth
 segment).

 How about a full type system that would make Java programmer scream? I'm
 sure with a bit of thought we can make one heavier than Java.


 Java is not PHP.
 Java does not have 32 bit int on 32 bit machines, 64 bit int on 64 bit
 machine.
 Java has concrete byte, short, int, long type. It's whole different story.



 BTW, I noticed that mt_rand() behavior has changed to raise E_WARNING for
 too large numbers.
 This is good change because PHP is known to generate very weak random
 number with invalid
 min/max.

 [yohgaki@dev ~]$ php-5.6 -r var_dump(mt_rand(222,
 '999'));
 int(115282844144104926)
 [yohgaki@dev ~]$ php-7.0 -r var_dump(mt_rand(222,
 '999'));

 Warning: mt_rand() expects parameter 2 to be integer, string given in
 Command line code on line 1
 NULL

 This behavior is much better. I mean E_WARNING and return NULL from
 function is
 much easier than dealing with E_RECOVERBLE_ERROR.

 Strict mode may stay as it is, but shouldn't we have consistent behavior?
 Internal function raises E_WARNING for too large int while user function
 raises E_RECOVERBLE_ERROR
 does not make much sense.

 Regards,

 P.S.
 With strict_types=1, mt_rand() gives

 Fatal error: mt_rand() expects parameter 2 to be integer, string given in
 /home/yohgaki/t.php on line 3


 --
 Yasuo Ohgaki
 yohg...@ohgaki.net




-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] is_digits() and digits type

[Walter Parker]

For recordID parameters, I think the only to get what you want is use a
class and strongly type the objects. I deal daily with code that assumes
things that look like integers are integers. As far as integers go, 123456
and 000123456 are the same. As record keys, they don't have to be the same
(it is a bad design). Without adding a 64 int type to 32 bit PHP, you can
not fix this in 32 bit land and keep PHP looking like PHP.

I guess this breaks down to the following two choices: In 32 bit PHP, what
is the proper response to an API that uses 64 integers? Should the values
be treated as strings or as integers. If treated as strings, they they can
perform all the functions of database keys and any other purpose that
treats them as tokens. If used as integers, then you set your code up for
failure. Anybody that casts or coverts them to ints has just set themselves
up for failure at some point in the future.

I'm not sure how we can fix the problem of people that see something that
looks like an int so they want to call it an int, regardless of the fact
that that is the wrong thing to do. But I don't blame you, as this sort of
mislabeling happens throughout society (just look at politics and the
misuse of labels there).

As far as the idea that most PHP won't use type hints correctly (to me,
that reads Most PHP programmers don't care about the code they write or
are too stupid to see the problems), maybe we could require that PHP
programmers get a license that requires that they understand how to use the
language correctly. Maybe we could fire them or ask them to use a simpler
language that doesn't require them to understand important details. I hear
you can still get BASIC.

 If you don't want you code to break when you 64 bit ints, either check for
size type and blowup/give a warning that your library is not compatible
with 32 bit ints or face the reality that the keys must be stings or
objects if you want your code to run without errors on 32  64 systems
without error.



On Thu, May 14, 2015 at 1:17 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 Hi Walter,

 On Fri, May 15, 2015 at 2:49 AM, Walter Parker walt...@gmail.com wrote:

 Adding a numeric pseudo type will not fix abuse, it will only change the
 abuse. I don't think it is worth the effort. I also think it might a
 slippery slope to lots of other pseudo types and other half ideas that will
 add complexity to the language without much in the way of benefit.


 Pseudo type is not abuse if it's there.
 Almost all PHP programs treated external values as string. PHP handled it
 somewhat nicely by type juggling.

 In PHP, integer like values are treated

 signed 32 bit int:  32 bit CPU
 signed 53 bit int:  32/64 bit CPU (IEEE 754 double)
 signed 64 bit int:  64 bit CPU
 arbitrarily int: 32/64 bit CPU (string digits is good enough for
 databases/etc IDs)

 If arithmetic is needed, we could assume it has at least signed 53 bit
 int. If arithmetic is not needed, we could assume
 arbitrarily int. I usually don't need integer arithmetic correctness much
 because most arithmetic are very
 simple. Examples are adding/subtracting date, stock, counter which will
 never exceeds signed 53 bit int range.

 On contrast, I need strict correctness for record IDs. Valid IDs should
 never raise error/exception.

 Use of type int type hint reduces reliable range to signed 32 bit int.

 The mixing of types, casts and validations can cause problems. I don't see
 how adding pseudo types will actually fix this as this appears to a
 validation problem and not a typing problem.


 Validations should not cause problems. If it does, the way validating data
 is wrong.

 I understand what's wrong with int type hints, yet I have to fight
 against temptation
 using it when signed 64 bit int is enough for my code/system. Vast
 majority of
 PHP programmers would use int type hint without considering the
 limitation and
 consequence.

 Anyway, we need at least numeric value validation (safe cast) function.
 Without it,
 strict_types=1 is harmful especially because people will just use casts
 which hides
 problem is their code.

 I don't expect PHP's int type hint accept arbitrarily numbers even when
 GMP int
 is fully integrated. PHP is made for web and interaction. JSON supports
 numeric
 that has undefined(unlimited) precisions, databases support huge numbers.
 Advocating
 users to use string type hint for these seems impossible. We'll see the
 result soon.

 Regards,

 --
 Yasuo Ohgaki
 yohg...@ohgaki.net




-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] is_digits() and digits type

[Walter Parker]

On Tue, May 12, 2015 at 12:27 PM, Lester Caine les...@lsces.co.uk wrote:

 On 12/05/15 19:55, Rowan Collins wrote:
  For instance, valid input for a 64-bit signed integer in a database
 could include:
  - any PHP native integer (assuming nobody builds with 128-bit ints!)
  - any string consisting of all digits, such that when interpreted as an
 integer the value won't exceed 2^64-1
  - any string consisting of a '-' followed by digits, such that the
 magnitude of the integer interpretation wouldn't exceed 2^64
  - any PHP float with no fractional part, maybe capped to a magnitude
 less than 2^53 for safety

 BUT
 In INTEGER in a database is 32 bit and will remain 32 bit, just as
 SMALLINT is 16 bit ... 64 bit is BIGINT and so the whole concept of
 simply ignoring 32 bit and handling them instead as 64bit is wrong!
 So type hints are broken before they start!

 --
 Lester Caine - G8HFL
 -
 Contact - http://lsces.co.uk/wiki/?page=contact
 L.S.Caine Electronic Services - http://lsces.co.uk
 EnquirySolve - http://enquirysolve.com/
 Model Engineers Digital Workshop - http://medw.co.uk
 Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php

 Yes, you understand the problem. PHP type hints are for PHP variables and
PHP types. External applications that have types with the same names and
different sizes can not use PHP type hints. Until and unless a majority
block of voters appears and is willing to add a full suite of types that
match external applications (8, 16, 32, 64, etc bit Integers, 32, 64, 80
bit floats, plus maybe the decimal types and the bignum types), you will
not be able to create scalar variables that track the types of external
data types. As some of the major committers are actually against adding
this sort of complexity to PHP, it is unlikely to happen.

For external data types, I don't see a good path other than classes for
tracking the data types.

How about a different type of RFC. How about adding the ability to add your
own scalar types to the language. Then people that want to write C++/Java
in PHP can define all the types they like. I'm sure that It could be done
in time for a PHP 8 or PHP 9.



Walter


-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] is_digits() and digits type

[Walter Parker]

You know, given how worried you seem to be about this issue, could you
booby trap your so that if the developers use the wrong type (int vs.
string) the program throws fatal errors with nasty error messages that
explain how much trouble the developer is in at the userland code level?

While I like the of protecting idiot developers from themselves, I'm still
not sure that this isn't a half solutions that just hide the pieces of the
problem that it doesn't solve.

I don't think we can solve the problem of developers not writing code
correctly or QA would mostly be out of job (instead of being a growth
segment).

How about a full type system that would make Java programmer scream? I'm
sure with a bit of thought we can make one heavier than Java.


Walter

On Mon, May 11, 2015 at 5:56 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 Hi all,

 Firstly, I don't intend this for PHP 7.0 strictly.

 PHP is made for Web. It means PHP is made for interacting other
 systems/data. Currently, we only have int and float strictly bounded
 to native unsigned int and IEEE 754 double. This causes problems
 for interacting other systems/data.

 Conversion to native data type causes problem like RFC 7159 6 Numbers
 points out.
 https://tools.ietf.org/html/rfc7159
 PHP's int is more limited because safe value is least common and it's
 signed 32 bit integer.


 To resolve this issue, how about to have

  - is_digits() and digits type for digits only inputs(integer like string)
  - is_numeric() and numeric type for float like string

 These check if variable contains only digits or float like string.
 It's pseudo type, but it prevents developers to specify int/float type
 wrongly.
 These may be extended to allow GMP int/float.

 Having these make sense for a language made for interaction and make basic
 type hint use intuitive. IMO.

 I wouldn't like to write too long mail. My thoughts and concerns are in my
 blog
 mostly.


 http://blog.ohgaki.net/php7-is-going-to-be-strictly-typed-language-will-this-work
 http://blog.ohgaki.net/dont-use-php7-type-hint-for-external-data

 Any comments?

 Regards,

 --
 Yasuo Ohgaki
 yohg...@ohgaki.net




-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] Adding numeric type hint

[Walter Parker]

On Wed, Apr 29, 2015 at 11:40 PM, Arvids Godjuks arvids.godj...@gmail.com
wrote:

 Stop trying to fix clever idiots from shooting themselves in the foot. The
 standard result from these actions is to make life a pain for regular or
 better programmers while only adding mild speed bumps to those clever
 idiots.

 Things like a numeric type will only encourage the clever idiots to write
 half broken code.


 Hello, just want to chip in.

 I use INT UNSIGNED for the MySQL primary keys since ages, because
 negative primary keys make no sense. Well, mostly ID's for the records
 actually can stay strings, but I will have to remember to use a string type
 hint every time I pass a record ID. I expect a lot of times to forget that
 and write int...
 I was bitten a few times by the limits of 32 bit integer sizes too (moved
 to a 64 bit server that time), but there are also unsigned 64 bit integers
 that can and will be used in math operations and passed around. And we
 don't have the unsigned int.

 Okay, we have GMP. I will have to use it. But let me just ask - if I work
 with a DB handling 64 bit integers (all I know handle them) or use a
 DECIMAL field - automaticly use GMP then? Oh gosh

 Arvids.


I think you point out an interesting problem. It sounds like you designed
the DB in isolation from the languages that would use it and then
discovered after the fact that using the entire space (because it sounds
like a good idea in isolation) can make life tough. Using a signed int
would have only reduced your space by half. In many cases, it you need that
extra space, you need more than twice and the difference between signed and
unsigned is not relevant. If the code and DB are matched, then you don't
have these problem. I'd suggest we make sure that we fix it in the right
location (I don't think a numeric type is the right location).


Walter

-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] Adding numeric type hint

[Walter Parker]

On Wed, Apr 29, 2015 at 11:54 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 Hi Arvids,

 On Thu, Apr 30, 2015 at 3:40 PM, Arvids Godjuks arvids.godj...@gmail.com
 wrote:

 Stop trying to fix clever idiots from shooting themselves in the foot. The
 standard result from these actions is to make life a pain for regular or
 better programmers while only adding mild speed bumps to those clever
 idiots.

 Things like a numeric type will only encourage the clever idiots to write
 half broken code.


 Hello, just want to chip in.

 I use INT UNSIGNED for the MySQL primary keys since ages, because
 negative primary keys make no sense. Well, mostly ID's for the records
 actually can stay strings, but I will have to remember to use a string type
 hint every time I pass a record ID. I expect a lot of times to forget that
 and write int...
 I was bitten a few times by the limits of 32 bit integer sizes too (moved
 to a 64 bit server that time), but there are also unsigned 64 bit integers
 that can and will be used in math operations and passed around. And we
 don't have the unsigned int.


 Use of unsigned int8 for ID makes sense almost always if database supports
 it.
 I may do such mistake even if I know I should use string (or numeric)
 for record IDs once I
 start using type hints.

 Okay, we have GMP. I will have to use it. But let me just ask - if I work
 with a DB handling 64 bit integers (all I know handle them) or use a
 DECIMAL field - automaticly use GMP then? Oh gosh


 I'm planning to introduce type affinity like SQLite. Then appropriate
 types for the value may
 be used automatically/semi-automatically. It's good for both security and
 performance.

 Regards,

 --
 Yasuo Ohgaki
 yohg...@ohgaki.net



Great! A Class or RFC that defined types that mapped one to one to DB types
sounds useful.

But this is not the same thing as generic pseudo type that are little more
that predefined regexs applied to strings (a.k.a the numeric type).



Walter

-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] Adding numeric type hint

[Walter Parker]

On Wed, Apr 29, 2015 at 11:47 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 Hi Walter,

 On Thu, Apr 30, 2015 at 3:12 PM, Walter Parker walt...@gmail.com wrote:

 And that is relevant how? How many Android phone run PHP applications?


 Search web for IoT devices that can run PHP.

 Regards,

 --
 Yasuo Ohgaki
 yohg...@ohgaki.net



You didn't answer the question: why should we care? Is there enough of user
base now to care? IOT might be able to run PHP, but how many actually do?
And of the ones that do, is automatically half fixing the code that bad
programmers might write for the last remaining 32 bit platforms a good use
of our time?

I don't see the numeric type as fixing any of these problems...


Walter

-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] Adding numeric type hint

[Walter Parker]

On Thu, Apr 30, 2015 at 12:06 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 Hi Walter,

 On Thu, Apr 30, 2015 at 3:54 PM, Walter Parker walt...@gmail.com wrote:

 You didn't answer the question: why should we care? Is there enough of
 user base now to care? IOT might be able to run PHP, but how many actually
 do? And of the ones that do, is automatically half fixing the code that bad
 programmers might write for the last remaining 32 bit platforms a good use
 of our time?


 I don't suppose anyone objects view that IoT will be a big market in near
 future.
 The main problem is not only code IoT developers write, but libraries used
 by them.
 If you know embedded devices, they care every single dollar costs. I don't
 see
 any reason that they use 64 bit CPUs while 32 bit CPU is enough.

 We may say using PHP and it's library is not safe, so don't use it.
 I just don't like to say or anyone else say this.


 I don't see the numeric type as fixing any of these problems...


 Which is easier to advocate?
  - Use string type hints for record ID/etc and validate value by
 yourself.
  - Use numeric type hints for record ID/etc.
 or even
  - Use _weak_ mode int type hints (If it's relaxed)

 Regards,

 --
 Yasuo Ohgaki
 yohg...@ohgaki.net


I didn't says there wouldn't be big. I think they could be giant. What I
said is that I think you are trying to solve a 1% edge problem that might
not be much of an issue when the are bigger problems and better solutions.

In an IOT where cost matter, using PHP is usually a poor design decision.
There are better languages. If costs matter, use the proper language for
this sort of environment (or use PHP correctly). I do not accept the
argument that we must use 32 bit CPUs and 32 bit PHP, but then go and use a
64 bit DB. Use a 32 bit DB, or restrict your self to 31 bit keys (or just
use strings). How many IOT systems use a language like PHP and not some
simplified system (picoBasic, microJava). I've worked on embedded systems.
When I worked with real world, cost sensitive systems, we used C, or a
stripped down language. Not a language like PHP. Note, Android uses Davik
(Java) or C/C++. iOS uses Objective-C, Windows Phone uses C#. All compiled
languages with mostly static type systems that map to the type systems of
the DB using a richer set of native types. PHP is not in a race to spread
to any and all platforms, regardless of suitability. Let's use the right
tools for the job.

You do know that you that can control the schema of the DB. Have you
suggested to SQLite that they make the default schemas PHP safe (instead of
making PHP SQLite safe). Why should PHP dance to SQLite's tune rather than
SQLite dancing to PHP's tune? I know this is a PHP mailing list, but PHP is
not the end all, be all of programming languages and anybody programming
IOT devices should know that. I'd prefer not to mess up PHP for its primary
market while trying to fix side issues for secondary targets.

I thing using string type hints are are easier to advocate (and I think
they are the correct type if you need to be 32/64 indepentent).
Otherwise, a numeric type doesn't fix the problem. It hides it. It is a
short term that doesn't scale properly.

Use int hints correctly. There are still new, if we start using the
incorrectly, things will only get worse.


Good night.


-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] Adding numeric type hint

[Walter Parker]

On Thu, Apr 30, 2015 at 7:35 AM, Levi Morrison le...@php.net wrote:

 This numeric type is a type of int or float. There is a formal name
 for such types: union types. Some languages have syntax for union
 types that would look like this: int | float. I have a draft RFC for
 this subject: https://wiki.php.net/rfc/union_types. Union types would
 be useful for other common cases as well, such as `Foo | null` or
 `array | Traversable`.

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php


Yes, this a union type. As I understand the request, the union type
definition would look like int|float| string where is_numeric(string) is
true. According to the definition of is_numeric, it does not check to see
if the string can be cast into an int or float, only that it could parsed
an stuffed into a bignum or GMP object.


Walter


-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] Adding numeric type hint

[Walter Parker]

On Wed, Apr 29, 2015 at 10:42 PM, Stanislav Malyshev smalys...@gmail.com
wrote:

 Hi!

  int Cast is bad. Incorrect int type hint worse as it could trigger
 DoS.

 I do not see any potential for DoS here. Trying to assign security
 implications so it looks like disagreeing with you jeopardizes security
 is not a good idea. If your code accepts non-numeric data and puts it to
 functions that except integers without validation, it is bad code and
 numeric hint would not help here, as unvalidated data can contain
 anything. If unexpected input causes denial of service in your code, it
 is a code architecture problem, which should not be solved by adding
 stuff to PHP.

  It's not all, but the main issue here is 32 bit CPU  PHP int is too
  small for
  database record IDs.

 Correct way to go there is treating these IDs as strings or objects and
 having code that handles them properly. If they do not fit PHP int, they
 should not be used with functions that expect int.

  To maximize compatibility, arbitrarily size of int/float like
  string/value should be
  accepted as numeric(or int/float).

 No, it should not be, since they are neither int nor float.


I have to strongly agree with Stanislaw here. If you are getting strings
from the DB because they don't fit in int, leave them as strings. If
someone breaks the code by adding the wrong type hints, then they have
broken the code.

Stop trying to fix clever idiots from shooting themselves in the foot. The
standard result from these actions is to make life a pain for regular or
better programmers while only adding mild speed bumps to those clever
idiots.

Things like a numeric type will only encourage the clever idiots to write
half broken code.

We just had to fix ZIP codes because the look like integers, so they get
processed and stored as integers. But this can break things when dealing
with New Jersey, which has ZIP codes like 07101. If you drop the lead zero,
then you have a different string/number and it can (and does) cause issues.


Walter


 --
 Stas Malyshev
 smalys...@gmail.com

 --
 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

Re: [PHP-DEV] Adding numeric type hint

[Walter Parker]

On Wed, Apr 29, 2015 at 10:50 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 Ryan,

 On Thu, Apr 30, 2015 at 1:29 PM, Ryan Pallas derokor...@gmail.com wrote:

  On Wed, Apr 29, 2015 at 8:37 PM, Yasuo Ohgaki yohg...@ohgaki.net
 wrote:
 
  Hi Rowan,
 
  On Thu, Apr 30, 2015 at 11:17 AM, Yasuo Ohgaki yohg...@ohgaki.net
  wrote:
 
  
A fatal error wouldn't constitute a DoS vulnerability, would it?
  
Attacker may inject huge ID value and/or they may simply access
   web sites to reach 2 billion limit, for example.
  
  
   That's not a DoS vector unless you've also done something else wrong,
   it's just an embarassing error like many others. A lot of the time,
  the DB
   will overflow first anyway, because an SQL int is signed 32-bit.
  Hell,
   YouTube had a 32-bit int for number of views until Gangnam Style
  overflowed
   it!
  
  
   Not really. Primary key is out of user control almost always. However,
   suppose code allows to specify foreign key and code assumes that non
   existing foreign key results in search query failure.
  
   Current PHP: Search query failure.
   New PHP type hint: Fatal error because foreign key is out of PHP int
  range.
 
 
  How is this different than other languages with type hint? For example,
  Java or C# - if you type hint int you are limited to 32bit. These
 languages
  have long and bigint respectively to support 64bit, but type hinting int
  means you cannot have arbitrarily large numbers.
 
  To me it sounds like you're trying to solve an application problem but
  suggesting a change to the language.
 
  
   If user are using type hints everywhere, it may be limited to
 attackers
   seeing fatal errors. If not, attacker can succeed system wide DoS
  attack by
   simple operation.
  
 
  I should have mentioned that I'm supposing DBMS like SQLite here.
  As we know, SQLite column accepts any value including value beyond 64
 bit
  int.
 
  https://www.sqlite.org/datatype3.html
  (Those who don't now Type Affinity, please read the section)
 
  From your link  The value is a signed integer, stored in 1, 2, 3, 4, 6,
  or 8 bytes depending on the magnitude of the value. And take a look at
  http://jakegoulding.com/blog/2011/02/06/sqlite-64-bit-integers/ where
  numbers larger than the max are converted to real on storage sometimes,
  depending on the affinity of the storage type chosen but not on math.
 

 As PHP int type hint does not accept huge float as int, it does not matter,
 does it?

 ?php
 function foo(int $v) {
   echo $v;
 }

 foo('1.0e+33');
 ?

 Fatal error: Argument 1 passed to foo() must be of the type integer, string
 given, called in - on line 6 and defined in - on line 2


 SQLite is the most used RDBMS in the world.
 
  I would love to see some empirical data that supports this claim.
 

 You know number of mobile devices? All Android/iPhone have it.
 Use of SQLite is not limited to phone, but almost every embedded device.

 It's about PHP was and PHP currently is.

 PHP didn't have any issues with huge record ID at all, but it can result
 in DoS not limited to targeted, but including site wide. Bad news for me
 is these DoS could be triggered by upgrade of library/etc that supports
 PHP7 type hints, not the code that I've authored or supervised.

 Anyway, too strict weak type hint cases problems any external inputs.
 There should be a resolution.

 Regards,

 --
 Yasuo Ohgaki
 yohg...@ohgaki.net



And that is relevant how? How many Android phone run PHP applications?

How many embedded devices of this type run PHP? If you are running a 64 bit
DB and a 32 bit PHP, change one to the other size or pay attention to your
sizes. Or stop using code from people that don't care to program correctly.

I'm sure I could find half a dozen metrics to make something else number
one (I'd put flat files at 1, a Mainframe DB at 2, and some PC db at 3).


Or just live with the fact that it not reasonable to expect that the system
will handle all of type checking for you without people having to think how
to refactor code to include type hints.

The resolution is simple, check your data before you hand it to third
parties if you don't trust them. Use unit and integration tests to alert
you for libraries where this might occur.


Walter
-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] Adding numeric type hint

[Walter Parker]

On Wed, Apr 29, 2015 at 7:37 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 Hi Rowan,

 On Thu, Apr 30, 2015 at 11:17 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 
   A fatal error wouldn't constitute a DoS vulnerability, would it?
 
   Attacker may inject huge ID value and/or they may simply access
  web sites to reach 2 billion limit, for example.
 
 
  That's not a DoS vector unless you've also done something else wrong,
  it's just an embarassing error like many others. A lot of the time, the
 DB
  will overflow first anyway, because an SQL int is signed 32-bit. Hell,
  YouTube had a 32-bit int for number of views until Gangnam Style
 overflowed
  it!
 
 
  Not really. Primary key is out of user control almost always. However,
  suppose code allows to specify foreign key and code assumes that non
  existing foreign key results in search query failure.
 
  Current PHP: Search query failure.
  New PHP type hint: Fatal error because foreign key is out of PHP int
 range.
 
  If user are using type hints everywhere, it may be limited to attackers
  seeing fatal errors. If not, attacker can succeed system wide DoS attack
 by
  simple operation.
 

 I should have mentioned that I'm supposing DBMS like SQLite here.
 As we know, SQLite column accepts any value including value beyond 64 bit
 int.

 https://www.sqlite.org/datatype3.html
 (Those who don't now Type Affinity, please read the section)

 SQLite is the most used RDBMS in the world.

 MySQL supports unsigned 64 bit integer also, BTW.

 Regards,

 --
 Yasuo Ohgaki
 yohg...@ohgaki.net


Are you asking to have both the 32 and 64 bit versions of PHP fully map to
the type system in SQLite? The type system in SQLite appears to have been
setup to map to programming language that lots of types (modern C, C++,
maybe Java) rather than PHP.

I think you might have an easier time fixing the SQLite adaptor for PHP
than making both 32 and 64 bit PHP map to the type structure for SQLite
completely transparently with full type defs.


-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] Adding numeric type hint

[Walter Parker]

On Wed, Apr 29, 2015 at 9:33 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 Hi Walter,

 On Thu, Apr 30, 2015 at 11:52 AM, Walter Parker walt...@gmail.com wrote:

 Are you asking to have both the 32 and 64 bit versions of PHP fully map
 to the type system in SQLite? The type system in SQLite appears to have
 been setup to map to programming language that lots of types (modern C,
 C++, maybe Java) rather than PHP.

 I think you might have an easier time fixing the SQLite adaptor for PHP
 than making both 32 and 64 bit PHP map to the type structure for SQLite
 completely transparently with full type defs.


 It's not a SQLite/etc access library issue, but the user code issue.

 Average PHP users will use int type hint for record IDs. This results in
 fatal
 error (or exception). These code does not have to be my/your code, but
 other libraries written by someone else.

 Regards,

 --
 Yasuo Ohgaki
 yohg...@ohgaki.net



Then this is exactly why we need type hints. If the average user is using
32 ints to map to 64 bit values, then someone has written broken code. The
code should fail with a type check error, not be automagically fixed if you
are using types. At some point the programmer should take responsibility
for matching the DB API to the code base. Hiding mistakes only sets up the
uninformed users for mistakes later.

Mixing 32 bit code/sizes with 64 code/sizes requires that you pay some
attention to sizes. Do everything in 32 bit, not a problem. Do everything
in 64 bit, not a problem. Mix the two and there is a cost. As far as a I
can tell, they is little desire in the current day to make the 32/64 hybrid
modes easier/simpler. This is a fact that people will have live with (or do
the work themselves). I see it as a legacy issue that is becoming more and
more irrelevant.

It would be nice to help, but it may setup future legacy issues that we
would rather not support.


Walter

-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

[PHP-DEV] Removing from git history

[Walter Parker]

From: Pierre Schmitz pie...@archlinux.de
To: internals@lists.php.net
Cc:
Date: Sat, 25 May 2013 05:48:07 +0200
Subject: Re: [PHP-DEV] Re: About fileinfo test.mp3
Am 24.05.2013 23:38, schrieb Anatol Belski:
 Hi David,

 On Fri, 2013-05-24 at 23:28 +0200, David Soria Parra wrote:
 Hi Anatol,

 I saw your commit 74555e7c26b2c61bb8e67b7d6a6f4d2b8eb3a5f3 added a 4mb
 mp3 file. Is it possible to create a much smaller mp3 that helps to
 reproduce the same bug? The file blows up the taball file for the final
 release, which I hope to keep as small as possible.

 Thanks in advance,
 David

 yep, I'm working on that currently. That file was additionally reported
 as containing some copyrighted song. Never looked inside though :) .
 I'll fix that at least by tomorrow.

 Regards

 Anatol

Hi,

is there a sane way to completely remove that file from the git history?
Having a public git mirror might get me into trouble and I am probably
not the only one.

Also: WTF?

Greetings,

Pierre



Gitub has a nice write at https://help.github.com/articles/remove-sensitive-data

The short sort is that to remove it from the history you need to apply
'git rm' as a filter-branch to your repo. Two items of note, anyone
that has pulled will have to rebase and if you really want it removed
(no direct access even with the commit's SHA1 key), the remote can't
be updated with a push. It will have to deleted and replaced with a
repo that was updated with the filter-branch. Also note that this may
effect tagging.


Walter

--
The greatest dangers to liberty lurk in insidious encroachment by men
of zeal, well-meaning but without understanding.   -- Justice Louis D.
Brandeis

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php