Re: [PHP-DEV] password_verify() and unknown algos

[Anthony Ferrara]

On Wed, Jan 27, 2021 at 11:27 AM Benjamin Morel 
wrote:

> Hi internals,
>
> I just spent some time debugging an authentication issue after upgrading
> PHP, and realized that it was due to ext-sodium not being installed, so
> password_verify() would always return false for argon2i hashes.
>
> Digging a bit more, I realized that password_verify() does not complain if
> the algorithm is unknown, or if the hash string is malformed:
>
> var_export(password_verify('passw0rd', 'any/string%as|a$hash')); //
> false
>
> Shouldn't it throw an exception, or a least trigger a warning, when the
> algorithm is unknown, or the hash is malformed? Returning false IMO, should
> mean "I recognize this hash, but it doesn't match your password". "I don't
> recognize this hash" is an application issue and should be reported.
>
> What do you think?
>
>
Hey all,

I just wanted to drop in and make a note here. When I designed
password_verify, the lack of validation/errors on invalid hases was 100%
explicit and intentional. The primary reason is to support multiple
validation strategies in order to allow for migration paths between
different storage mechanisms.

Take an example where someone used to use Wordpress's custom phpass based
$P$ system. They now want to migrate to bcrypt/argon/etc. If
password_verify threw errors the validation system would need to introspect
each hash to determine how to validate it (note, this happens in
password_verify and the other validators already). But without errors, it
becomes a simple fallthrough:

function validate($password, $hash) {
if (password_verify($password, $hash)) return true;
if (legacy_verify($password, $hash) || other_legacy_verify($password,
$hash)) {
update_password_hash($password);
return true;
}
return false;
}

There are definitely a fair number of applications that use the above
method to ensure backwards compatibility and a solid upgrade path, and as
such I would be resistant to adding warnings/errors/exceptions here.

The case for "it's an application issue" is definitely valid, though that's
also what password_info was added to provide (it is easy to introspect).

One other point I'd make is to normally suggest not disclosing any
information about cryptographic material via error handling mechanisms
(it's too easy to expose to attackers). This is one of those dev-x/security
tradeoffs. Does not throwing a warning improve security? Not in most cases.
But can throwing a warning make an attackers job easier (or at least point
them in the right direction)? Perhaps.

My $0.02 at least

Anthony

— Benjamin
>

[PHP-DEV] [RFC] [Withdrawn] Adopt Code of Conduct

[Anthony Ferrara]

All,

I've decided to withdraw the CoC RFC. There are many reasons for it,
but there are a few points I want to make.

As to the content of the RFC, when I initially proposed it, I selected
the Contributor Covenant due to it being a well adopted standard.
Several people raised objections to it, and I was completely open to
changing it. But the more objections I see, the more I feel the nature
of the objections actually justifies the Covenant as the choice rather
than justifies switching it. The more I hear people complain about the
"scope of applicability" being outside the project, the more it's
apparent that many (not all, but many) simply don't want to need to
think about their actions in other contexts. Some will claim that
ambiguity will lead to abuse, but the underlying idea is "treat people
with respect". And as long as you do that, all will be fine.

And while several would rather see a CoC that focuses on "positive
behavior", to me that's not what a CoC is for. The CoC is to take a
stand and say "this is what we will not tolerate". Positive behavior
should be encourage in another "Contributing" document. Where you
detail how people should contribute. The CoC is a mechanism for people
to feel safe. And safety is achieved by taking a stand.

As far as voting on just the CoC without a private reporting mechanism
(which implies some degree of "teeth"), I've made it clear that I
don't believe that's tenable. I believe that asking people to go
public with every incident defeats the entire point of having a CoC.

I am also not happy with the RFC in its current state (I've been clear
about that since day one). But I also have no further energy to evolve
it further. Hence, there is nothing left for me to do but withdraw it.

Thanks

Anthony

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Anthony Ferrara]

David,

On Mon, Jan 11, 2016 at 5:05 PM, David Zuelke <d...@heroku.com> wrote:
> On 11.01.2016, at 12:31, Anthony Ferrara <ircmax...@gmail.com> wrote:
>
>> Actually, asking for proof and denying are the same thing. If they
>> weren't, then why would you be asking for proof unless you believed it
>> didn't happen?
>
> They are not the same thing. If you make a claim, then the onus of proof is 
> on you, and you cannot simply turn that reasonable request against them by 
> then implying they're denying. Otherwise, why have proof for anything at all?

Because the claim is tangential to the discussion. We're not talking
about passing an RFC which enumerates which incidents have happened.
The fact that incidents have happened doesn't change this RFC at all.
Some people denied that anything has happened in the first place, and
as a response to that, many (including myself) have stood up and said
"sorry, but things have happened". The burden of proof isn't on
anyone, because the entire line of discussion is off-topic.

And even if it was on-topic, the question wasn't (sic) "can you share
a concrete example so we can learn from it". The question was (sic) "I
haven't seen it happen" which is paramount to "prove it".

> To me, this begs the question: would you handle incidents covered by the CoC 
> in a similar way, with that same attitude? An accuser claims something, and 
> asking for proof will be interpreted as denial?
>
> By extension, will a third party asking for proof for an incident be subject 
> to kafkatrapping - "the fact that you're doubting X happened means you're 
> also guilty of X"? That one has happened to me before on twitter. Didn't 
> stick because of the ridiculousness, but maybe the conjured mob was simply 
> not large enough to spark sufficient outrage.

Which is precisely why asking for evidence and public discussion is
problematic. That's precisely what I was trying to avoid with having a
resolution team that had limited powers. To avoid the "public court"
as much as possible *precisely* because of the mob mentality *in both
directions*.

> I'm pretty uncomfortable that you as the person "in charge" of this RFC hold 
> such biased views. If you can't see that asking for proof and denial are 
> different things then that IMO disqualifies you for that role.

Ok. I'm disqualified then.

> The same applies to your claims of threats of violence. It's fine if you 
> don't want to provide details, but then you can't bring those cases up. It's 
> legitimate for others here to ask you for evidence if you do bring it up. I 
> understand that we're all different personalities and you're maybe more wired 
> in that direction (mentioning something in passing), but you need to 
> understand that once a claim is out there, it's up to you to back it up. If 
> you then refuse to, it raises doubts, and rightfully so.

I never said I don't want to provide details. I said I won't talk
about it publicly. I think that is a reasonable thing. Especially
since we're talking about creating a private channel for this sort of
discussion. To say I need to make it public or it doesn't count is
problematic. Especially since we're talking about a CoC here where
people may not feel comfortable talking publicly about incidents. And
several people have already stood up and said precisely that. So to
discount all of those incidents because people don't feel comfortable
(for whatever reason) talking publicly, isn't good.



Zeev,

> What clearly hasn't happened is any proponent of this RFC actually answering 
> these questions.

Because I (and others) believe that none of these questions are
actually related to the RFC. They are tangential and are distractions
from the prime point. The prime point is to actually figure out is
where we should move the proposal towards. Very few of the replies,
and none of the ones in the past 100 replies discuss this prime point.

IMHO answering these meta level questions, and having this meta level
discussion is a distraction from the entire point of the proposal.

> Is my email being ignored because I used the word 'judicial' to describe the 
> current RFC, and differentiate it from a regular CoC+mediation?
> Is it non constructive or hyperbole in your opinion?

No, I read your email. I haven't responded because I've been trying to
throttle my replies to this post, and had immediately responded to
another thread. Additionally, I don't believe that anything you
brought up hasn't already been discussed at some point in this 300+
reply thread.  But if nobody else covers the points I feel should be
made, I will reply tomorrow to it.

> Asking for proof is not at all the same as denying it exists.
> Not knowing that something exists, and even finding it difficult to believe 
> it does - is not t

[PHP-DEV] Status Of CoC RFC: (WAS: Adopt Code of Conduct)

[Anthony Ferrara]

All,

> If we want to deal with the reasons why people avoid internals, the let's go
> and analyze the problem first ? I will start asking whether we really want
> to attract newcomers. The question may sound ridiculous but I think we
> don't, mostly because most people here see newcomers as just a source of
> annoyment and silly questions/RFCs. Additional evidence shows that we never
> did much effort to help integrate newcomers.
>
> So, the tone on the list is, IMO, just a small part of the problem. As long
> as there's no consensus on whether we want to attract newcomers and the
> effort we're ready to do to integrate them, discussing about the details of
> a CoC seems a bit prematurate to me.

I am no longer going to participate in this email thread, as it's
ceased to be productive to any degree.

Keep in mind, the purpose of the thread is to work on the draft
proposal to guide it to a final state which would be proposed
officially (which it hasn't yet been). When the time comes that the
proposal is officially presented for discussion, arguments for and
against it can be made. But at this point, arguments are being
presented for a moving target and as such are more of a distraction
than constructive.

I will continue to work on this RFC. If you would like to have a
constructive discussion, please come find me. But I am not going to
tolerate this distraction that has absolutely nothing to do with the
proposal anymore. Yak-Shaving and Sea-Lioning have taken over the
discussion thread and led to absolutely nothing constructive in the
past 100+ replies.

If you would like to be constructive and help guide the proposal to
something that will work, feel free to reach out to me personally and
I will honor any constructive request. Some of us are meeting with
some of the people behind Drupal's CoC to collaborate on it. I expect
that discussion will drive the proposal significantly.

I expect that my next post on this subject will be presenting a final
proposal that I intend to open for voting after the required
discussion period.

Anthony

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Anthony Ferrara]

Stas,

On Mon, Jan 11, 2016 at 3:15 PM, Stanislav Malyshev  wrote:
> Hi!
>
>> I fail to understand how one can think that the CoC could be about
>> censorship  (which is basically what this comment says).
>
> I can explain you that very easily: there are known instances where CoCs
> were used and even more instances where there were attempts to use CoCs
> and CoC-like structures exactly for that. It's not a concern because
> people think it *might* happen, it's a concern because it *already
> happened* elsewhere and people think it also might happen *here*.

Can you cite examples of where this has happened before? Perhaps
studying those incidents will reveal insights we can use to prevent
it.

>> I also fail to understand how one can fail to accept that we already had
>> and have issues, despite numerous people having experienced it.
>
> That's because nobody does that. Instead, the question is whether the
> specific proposal is helpful to fix specific issues. The conversation
> goes like this:
>
> A: here's solution X!
> B: for what?
> A: for problem Y
> B: but do we have problem Y? Also, X does not seem to solve Y and also
> introduces problem Z
> A: we can solve Z easily! Also, here's proof problem Q exists.
> B: but Q is not Y. And we didn't see Y exists so far. And your solution
> to Z sounds iffy.
> A: why you keep denying problem Q exists?!

I don't think that's a fair characterization of this discussion. Some
people have questioned what this is a solution to, but most haven't.
Some have questioned if we have a problem, but most haven't.

Most of the constructive discussion (meaning the discussion not using
hyperbole or overloaded terms) has been not talking about if we need
to do something, but if what is proposed is good or not. And the best
parts have been help molding the proposal to be better overall.

>> create a somehow useful CoC. If we do not see us having problems, there is
>> no point to even discuss a document to solve non existant (for us) problems.
>
> As I note again, talking about abstract "having problems" as an argument
> to do a specific thing is not very useful.
>
>> As a side but important note, it is very disturbing to read so many of us
>> denying the very issues we have. Even if it is denied in a very diplomatic
>> way. I am convinced that this is the first problem we must solve to get a
>> CoC, to accept the very existence of these problems.
>
> First of all, asking for proof and denying is different thing (though
> people often confuse the two, but these *are* different). Second, "very
> issues we have" is, again, very unspecific thing, so it's not even
> possible to deny it. Before I could even deny that "these problems
> exist" - or before you claim I or anybody else does - I'd like to know
> what exactly are "these problems" in specific terms. Because some of the
> problems were almost unanimously recognized, some was not, so it's not
> clear what parts we are talking about.

Actually, asking for proof and denying are the same thing. If they
weren't, then why would you be asking for proof unless you believed it
didn't happen?

As far what exactly "these problems" are specifically, that's an
entirely different discussion than the one we've been having here as
part of the CoC. Because the vast majority of "these problems" aren't
the goal of the CoC. The goal of the CoC to me is to help create a
safe place. To create a mechanism and reinforcement that we should all
behave appropriately.

Other issues (such as over aggressiveness on the list, etc) are out of
scope right now, so aren't worth discussing *in this thread*. Feel
free to discuss it as much as you want in another thread, but I'd like
to see this one get back to constructively discussing the proposal.
Well, not really "get back to", but "start".

Anthony

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Anthony Ferrara]

Stas,

On Mon, Jan 11, 2016 at 11:00 AM, Stanislav Malyshev
 wrote:
> Hi!
>
>> least hold ourselves to a level of mutual respect. Going out and
>> calling someone a moron in public is not constructive nor respectful,
>> and IMHO we as a project shouldn't sit back and blindly say "whatever"
>> if it happens.
>
> OK, so what should we do instead? So far my calls to apply some TDD were
> not heard, maybe this time?
>
> Let's consider an example of twitter user drupliconissad. It may be
> genuine individual or a troll, it doesn't matter either way.
> If you read the feed, you can find much more than "moron". Now, had we
> had CoC, what would we do? We don't know who that is, so private
> moderation is out of the question, even if we did - it's not look like a
> personal conflict that can be amicably reconciled. Should we issue a
> proclamation saying "we think some anonymous account on twitter is being
> bad"? Should we ban that person (or group of persons - we have no idea
> either way), which we have no idea who that is, from our list? Any other
> ideas?

This particular case isn't what a CoC would protect. So I think that's
a bit of a red herring. The CoC doesn't try to enforce itself outside
of the scope of project members. Instead, it applies to project
members wherever they represent the project. So unless we learn that
the "drupliconissad" account actually was a internals contributor,
it's beyond the scope of the CoC considering it also happened
off-list.

However, as Ferenc indicates, what Phil Sturgeon has been saying on
twitter would be within the scope of the CoC, since he is a member of
the project and is actively discussing the project and its members in
a project-related context.

Anthony

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Anthony Ferrara]

Brandon,

On Mon, Jan 11, 2016 at 8:47 AM, Brandon Savage
 wrote:
>>
>> At the same time, though, if someone is being maliciously hostile what
>> great cover!  A private email is not a PHP-Group managed resource, so no
>> rules!  Twitter, ha, no rules!  Reddit?  LOL like they enforce anything.
>> If someone wanted to send a death threat to another developer about PHP
>> business, I would hope that, as a developer, they are at least smart enough
>> then to do so using a chat program that is "out of scope" so that they're
>> untouchable.  (If they tried to send someone a death threat on list, we
>> should ban them for stupidity. :-) )
>>
>> That's why the scope needs to cover "involves PHP business, regardless of
>> medium" rather than "just on certain pieces of server infrastructure".
>> It's trivial to circumvent otherwise.  Now, how do we define "involves PHP
>> business" in a way that, for example, forbids someone from harassing a gay
>> person about PHP business but doesn't penalize someone for participating in
>> an anti-gay-marriage protest in their home town?  That's the question we
>> should be discussing: How that balance works to minimize that risk, and
>> avoid it being abused to Eich someone.  (Yes, I just used Eich's name as a
>> verb.)
>> 
>>
>>
> Larry,
>
> This is a great point, and brings up an interesting potential compromise
> that might work well for solving this issue.
>
> If the issue is that someone might take an on-list discussion and harass
> someone off-list, why not limit the jurisdiction to individuals who have
> participated on-list in discussion or voted on the issue?

Honestly, this feels like an overly broad hole. It would be easy for
someone to harass off-list, and then just claim "well, I haven't been
part of the discussion for X, so doesn't count". Plus harassment isn't
limited to just discussion on a certain topic.

> And that to me is the crux of the issue. When it comes to making
> discussions on internals more civilized, governing a person's conduct *as
> it relates to their participation in the discussion* is about as far as PHP
> should go. A person who is not a party to the discussion, who does not
> vote, but does have karma, who happens to tweet "I think X is a moron for
> proposing Y" is entitled to that opinion, *until they bring it here.*

While everyone is entitled to their opinion, sharing that opinion is
potentially another story. I think the exact quote you bring here is
one of the things a CoC is designed to prevent. I would absolutely
consider it bad if one karma-holding individual calls another a
"moron" at all in public for proposing an RFC. While we may disagree
with someone, we should hold ourselves to a constructive standard. The
vast majority of people here want to see PHP (as a project) improve.
Even if we don't agree with how someone approaches that, we should at
least hold ourselves to a level of mutual respect. Going out and
calling someone a moron in public is not constructive nor respectful,
and IMHO we as a project shouldn't sit back and blindly say "whatever"
if it happens.

Anthony

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

Re: [PHP-DEV] PHP 7.1 - Argon2

[Anthony Ferrara]

+ Solar Designer

On Mon, Jan 11, 2016 at 7:55 AM, Rouven Weßling  wrote:
>
>> On 11 Jan 2016, at 13:27, Pierre Joye  wrote:
>>
>> Hi,
>> On Jan 11, 2016 4:12 PM, "Rouven Weßling"  wrote:
>> >
>> > * Is there already a crypt scheme for Argon2? Or are there any efforts to 
>> > define one? It would good if PHP wouldn’t be an island.
>>
>> https://github.com/P-H-C/phc-winner-argon2
>>
>> The reference implementation. If anything we should use it.
>>
>> I am not sure if we should bundle the library tho'.
>>
> Thanks for the link. The included example seem to use $argon2i$ and $argon2d$ 
> as crypt scheme. A cursory search didn’t show anyone else using Argon2 with a 
> crypt scheme, so this would probably be good enough.

To my understanding, the crypt scheme hasn't been formalized. Solar
Designer, can you confirm?

Anthony

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

Re: [PHP-DEV] Re: Anonymous voting on wiki

[Anthony Ferrara]

Stas,

On Sat, Jan 9, 2016 at 5:00 PM, Stanislav Malyshev  wrote:
> Hi!
>
>> This seems useful. I do wonder whether we should use by default for
>> RFCs. It's interesting to see how different people vote, and knowing who
>
> I think we talked about it, and decided not to do it. Anything changed?
>
>> One concern I have with the patch is that it doesn't appear (by my
>> reading of the code) to show who voted. I think it's important to know
>
> This is intentional. Otherwise by taking snapshots of the page at
> regular periods and seeing who voted and how the totals changed, one can
> deduce each personal vote.

Perhaps then show them once the vote is closed?

Anthony

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Anthony Ferrara]

All,

> I was not hesitant (or, let's maybe call it "intentionally procrastinating") 
> to post on this topic because I felt unsafe on this list or in the general 
> realm of the PHP community; I simply was in no mood to deal with a mob of 
> self-proclaimed-or-not "Social Justice Warriors" and their digital pitchforks 
> on twitter or elsewhere - and they're already trying: 
> https://twitter.com/drupliconissad/status/685489458934841344

Please, let's stop this rhetoric and propaganda. All of you.

Since day one supporters of a CoC have been attacked. We've been
called "SJW", "Fascists", "Feminists", and a whole more, and a whole
lot worse. Have you looked at Reddit? Have you looked at Twitter?
Hell, David just called us a "mob of self-proclaimed-or-not Social
Justice Warriors." Outsiders have joined that rally against "SJW" and
"Fascism" (and that's me being nice as to what they are saying).

Aside from Phil Sturgeon (who used unacceptably harsh language), the
people who support this have been exceedingly reasonable. We've been
trying to discuss logic. We've been trying to keep a level head and
talk compromise. We've been trying to come to a middle ground solution
that works for everyone. I've personally spent a lot of time talking
to people 1:1 constructively to try to figure out what the right
approach. We're reaching out to other projects to try to find a common
baseline. Not to pass something, but to pass the right thing. I've
said that in basically every reply to the entire discussion in every
thread I've been a part of.

Yet time and time again, we're attacked and accused. A perfect example
here is the obviously troll account cited here that looks like it has
a feminist agenda, and then call out for digital pitchforks.

This has got to stop. Please, be professionals. This thread is
currently 207 messages long. Out of that 207, the vast majority *FROM
EITHER SIDE* is either rhetoric, hyperbole or pure argument.

On a thread discussing a **DRAFT** proposal.

Please stop with the bullshit arguments about "power takeovers" or
"political crap" or "pitchforks" or the passive-aggressive comments.
Please stop with all of the distraction.

If you have something constructive to contribute that will help reach
a meaningful compromise, then by all means, let's discuss it. But
please keep the tone civil, and the attacks out of it.

But foremost, let's act like professionals.

Anthony

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

Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

[Anthony Ferrara]

Sara,

On Thu, Jan 7, 2016 at 8:16 PM, Sara Golemon  wrote:
> On Thu, Jan 7, 2016 at 2:51 PM, Zeev Suraski  wrote:
>> Having a CoC which is wider in scope and ratified by a voted RFC rather
>> than an email on some mailing list sends a strong message.  Having it in
>> our contributor guidelines would also go a long way.
>>
>> I guess here we fundamentally disagree - it seems that sending the message
>> that 'we take this seriously' - by placing strong emphasis on reporting and
>> penalties - is more important to some than agreeing about the values
>> themselves.  For me, the values themselves and communicating them properly
>> and prominently are infinitely more important than the policing mechanism,
>> as I believe that stating them clearly would go a very long way and is
>> anything but useless.
>>
> And maybe this RFC is trying to do too much at once.  Code diffs
> should be scoped to "one change per diff", and RFCs should as well.
>
> Anthony, would you be amenable to reducing this first RFC to just a
> code of conduct.  This is; Define expectations from members of the
> community.  No response team, no penalities (expressed or implied), no
> language about "accused/accused/offender/etc...".  Just: "all
> contributors and participants in the PHP project shall endeavor to be
> nice (list example ways of being nice) and avoid being mean (list
> example ways of being mean)".

No. I will be willing to cut scope overall to cut how much it tackles
in the first swing, but I strongly believe that there needs to be some
sort of non-public resolution process defined.

We've seen time and time again that the court of public opinion is a
horrific judge for these style issues. Just saying "these are the
things we believe in" without actually showing and providing a method
for people to feel safe in reporting if one of those beliefs are
violated is not good IMHO.

I'm 100% open to completely rewriting the RFC, to pulling in a
different CoC, to rewriting or reusing a different conflict resolution
policy. That's all 100% on the table. However, I will not support what
many are suggesting here that people will be required (even if just
initially) to report issues publicly.

Simply look at the level of attacks that me and a few other committers
have received by making this proposal. I don't feel comfortable making
any of those attacks public (drawing more attention to them). In
private, to a team that is trusted and has even a baseline set of
"powers" to at least report an incident with identifying details
redacted would be far better than just requiring people to "come
forward with any issue".

> Further evolution of that can come in later RFCs.  Or not if the
> community doesn't think we need an official point of contact and/or
> enumerated punitive actions.  Feeling the temperature in the room, I'd
> lay money that the third leg of that proposal wouldn't ever fly.  Even
> the second is questionable given concerns of confidentiality (or
> secretiveness, depending on your position).  I'd hope the first,
> simply stating expectations in a formalized way, will only have
> limited pushback (due to concerns of over/under-specific language),
> and we can take our time in reaching consensus on that one item.
>
> If we can't even agree on that first stage, setting expectations of
> profession behavior, then the rest of this conversation is irrelevant.

I think many do agree. If you look at this 225+ reply thread, the vast
majority of karma holding people have not responded (even many who
frequent this list). A few (5+) of them have reached out to me
personally to say that they are explicitly staying out of this
discussion because of the level of aggression and tone, but would be
willing to support a reasonable proposal (some provided meaningful
feedback on it, some support the current revision).

Think about that. People who are long standing members of this
community and project do not feel that they can safely respond to this
very thread. Think of the irony there.

One active community member (though does not have karma here) is
quoted to say "The tone of the 'discussion' is such that I wouldn't
dream of throwing in 2 cents, let alone attempt to spearhead real and
lasting change".

I think if the current RFC went to vote, it would come very close to
passing as-is. But as I've said before, I don't think it's anywhere
near ready to vote on. Larry has started a discussion with the people
behind Drupal's CoC, and I hope that leads to significant change and
clarity in the CoC and CRP that I'm proposing.

There's still significant work to be done, but I honestly don't
believe that the tone and content of this thread accurately represents
the majority opinion of karma holders, nor of the broader community.
The only way to know for sure would be to hold a vote (preferably a
blind one, but that's not really on the table). I don't believe the
current RFC is good as a final proposal, so I won't put it 

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Anthony Ferrara]

Keith,

On Fri, Jan 8, 2016 at 11:38 AM, D Keith Casey  wrote:
> On 1/7/16 11:52 PM, Larry Garfield wrote:
>>
>> On 01/07/2016 10:08 PM, Brian Moon wrote:

 Why not? The harassment has been nullified.
>>>
>>> I agree with your position on most of this, Paul. However, free email,
>>> and thus, Twitter and other social media accounts are nearly
>>> unlimited. It becomes an arms race to try and block someone.
>>>
>>> Brian.
>>
>>
>> Simply cutting off contact (either by the receiver of harassment or
>> otherwise) isn't the entire goal.  There are least 2 others:
>>
>> 1) Harassment does not need to be direct.  If I were to start tweeting
>> up a hostile, insulting storm about someone else on this list, by name
>> and talking about PHP Internals business, but not tweeting @ that
>> person, them blocking me isn't going to accomplish anything.  The harm
>> isn't that they are seeing the message necessarily, it's that everyone
>> else I know is seeing it, many of whom that person may not even know.
>> That's still an attack on a person's reputation, and damaging to the
>> person.
>
>
> Good scenario but we don't have to be hypothetical. Let's apply it to the
> real world of this week:
>
>
> Throughout this discussion, Paul Jones has been active and - despite vocally
> attacking the proposal - I have yet to see him attack anyone in general.
>
> And then Phil Sturgeon else used a sexualized term to insult Paul to his
> ~16k followers but didn't name him:  https://archive.is/oeekT
>
> While Phil claims this is not sexualized, Urban Dictionary disagrees but
> then he follows it up with a claim that he doesn't represent the project
> anyway: https://archive.is/TA2YP
>
> According to the definition including attending conferences that use the PHP
> logo and active in PHP channels, he does.
>
> And then Phil follows it up with another more potentially damaging attack -
> again, without naming Paul - https://archive.is/Z3zNy
>
> And finally, it turns out it's all Phil is blocking Paul anyway -
> https://archive.is/6iZQY - so Paul wouldn't even have see the attacks to
> defend himself or report to the PHP Code of Conduct group.
>
> So my questions:
> -  In his day to day interactions, would Phil be considered a representative
> of the PHP team?

In normal day-to-day interactions? No, I don't think so. In this case,
considering he's directly discussing the project at the time, I think
that it would be fair to say he is representing the project in
context.

> -  If not, why not?
> -  If so, do his personal attacks using sexualized terms constitute a breach
> of the Code of Conduct?

I think a strong argument could be made for that. Either way, I don't
think it's the level of comment or discussion we want to encourage, so
whether or not it's a "violation", it's definitely something that's
bad.

> -  If not, why not?
> -  If so, what would the consequences be for Phil?

Depends on the precise version we adopt. I think having someone step
in and say "Phil, cut it out" would be enough. Though if he continues
to do it, then we may want to escalate further.

In general, I think the fact that we tolerate that sort of behavior is
insane. The fact that many in this thread are suggesting that "it
didn't happen on list, so we shouldn't care" is extremely narrow. We
should hold ourselves to a higher standard. We should commit ourselves
to treating each other fairly and with respect, even if we disagree
with that person. I know I have crossed that line before. I've also
apologized each time, and am honestly working hard to not do that
again. None of us are perfect in this regard.

What we're talking about isn't a "if you're not perfect, get out".
It's a "we know you won't be perfect, but that doesn't mean we should
tolerate bad behavior either".

Anthony

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

Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

[Anthony Ferrara]

Kevin,

On Fri, Jan 8, 2016 at 10:39 AM, Kevin Smith <ke...@gohearsay.com> wrote:
>
>
>> On Jan 8, 2016, at 9:09 AM, Anthony Ferrara <ircmax...@gmail.com> wrote:
>>
>>
>> Simply look at the level of attacks that me and a few other committers
>> have received by making this proposal. I don't feel comfortable making
>> any of those attacks public (drawing more attention to them).
>
> Disclaimer: While I’ve followed this entire email thread, I’m sure I’ve 
> missed stuff that’s going on outside it. I was genuinely going to ask which 
> attacks you’re referring to until I got to that last sentence. It’s fair if 
> you don’t want to share, but your argument was for us to simply look at the 
> attacks you’ve received.

The vast majority of them were in public arenas. And a non-trivial
number of people on this list have witnessed it. So it's not like I'm
saying "blindly trust me"...

> If you’re referring to anything in this email thread (which again, that’s all 
> I can draw from), I’d worry about creating a body with powers to punish 
> attackers since we clearly don’t agree on what constitutes an attack. This 
> discussion has been contentious, sure, but it’s concerning a very serious 
> topic that would have far-reaching effects. I wouldn’t argue that anything 
> we’ve seen coming from any perspective rises to the level of an attack though.

I don't think anything in this thread warrants the term "attack" or
"harassment". While I strongly don't agree with the tone being used
nor the tactics being used, I don't think they warrant any sort of CoC
violation.

> Again, I’m happy to claim ignorance here because you may be referring to 
> things that have gone on outside this thread. But since you don’t feel 
> comfortable pointing to those attacks specifically, we’ve sort of reached an 
> impasse.
>
>> If you look at this 225+ reply thread, the vast
>> majority of karma holding people have not responded (even many who
>> frequent this list). A few (5+) of them have reached out to me
>> personally to say that they are explicitly staying out of this
>> discussion because of the level of aggression and tone, but would be
>> willing to support a reasonable proposal (some provided meaningful
>> feedback on it, some support the current revision).
>>
>> Think about that. People who are long standing members of this
>> community and project do not feel that they can safely respond to this
>> very thread. Think of the irony there.
>
> For what it’s worth, I’ve had 2 people reach out to me privately to say 
> they’re really uncomfortable with this proposal but don’t want to get 
> involved because they're worried about being labeled “toxic”, and I’m a 
> brand-new contributor. A real nobody.

Sure. I'm sure there are a lot more that aren't talking that are
against it. But I think you proved my point here which is that people
are afraid to share their opinion here. That is a strong indicator
that something isn't healthy *today*. It says nothing about the
potential solution, but it should act as a pretty strong heuristic
that "status quo" isn't really good either.

Thanks for the thoughts

Anthony

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

Re: [PHP-DEV] [RFC] Libsodium

[Anthony Ferrara]

Pierre,

>> Even if we axe mcrypt and in with a net-gain of 0 extensions, you'd
>> see it as a risk?
>
> Except that we already refused to kill mcrypt, and it is not like I
> did not try to convince us to kill it.

We decided not to kill it for 7.0. That doesn't mean it got a permanent buy...


>> Let me state this clearly: I'm personally not going to bother pushing
>> for a pluggable crypto API if the only option is to use OpenSSL and
>> all its legacy cruft. I especially don't have lukewarm feelings
>> towards RSA or ECDSA, which are your only real options with it.
>>
>> I feel that it simply would not be a worthwhile use of my time to do
>> so. If Internals decides "no libsodium" but "yes pluggable crypto
>> API", you'll have to find someone else to spearhead it.
>
> Sorry, my point was not clear.
>
> I do like the concept of a pluggable crypto API. Very much. I said it
> before and I say it again. I love the concept and will do what I can
> to support it :)
>
> What I do not like too much is the addition of an extension with
> (relatively) low level functions for one specific library. It does not
> really matter how good is this specific library, I simply do not see
> such addition as a good strategic move.

I agree with you in principle, but in this particular case I think
that there's enough justification considering how measurably bad
mcrypt is, and how little some people trust openssl. That leaves no
room in core. So in this case I think it *may* be worth it to add it.

Anthony

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

Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

[Anthony Ferrara]

Zeev,

On Thu, Jan 7, 2016 at 3:50 PM, Zeev Suraski <z...@zend.com> wrote:
>> -Original Message-----
>> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
>> Sent: Thursday, January 07, 2016 8:15 PM
>> To: internals@lists.php.net
>> Subject: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct
>>
>> All,
>>
>> On Mon, Jan 4, 2016 at 4:06 PM, Anthony Ferrara <ircmax...@gmail.com>
>> wrote:
>>
>> There has been some discussion asking for a split of the RFC into two.
>> I do not believe that this is a good idea, because the CoC is useless
>> without
>> some sort of resolution strategy (without *anything*). And if we do need
>> to
>> do something (which I firmly believe), then why not do it right the first
>> time. I
>> am more than willing to evolve this proposal significantly (it's no where
>> near a
>> final form). This discussion should help it evolve.
>
> First, I firmly believe that having a CoC - without anything extra - is
> anything but useless.  Values go a long way.  Telling people what you expect
> of them isn't only the first step towards obtaining that behavior - it's by
> far the most important step.  I suspect anybody who has kids (or that has a
> reasonably fresh memory of being a kid himself) should be able to vouch for
> that, and again, I'm bringing up the thesis that the vast majority of us
> here follow the law not because we're afraid of what would happen if we
> don't - but because it's the right thing to do.

We already have that: https://lwn.net/Articles/452278/

The point is many people believe that does not constitute a code of
conduct. It is a worth while thing to have, but it doesn't make the
assurances to others that the project takes bad behavior, harassment
and discrimination seriously.

And I agree with you about not doing something because it isn't right.
However, I'm not attempting to codify what's "right" here. Instead,
it's about communicating to others that we take these things seriously
and hence hold each other to a standard.

And if we don't have any means at all of holding ourselves to said
standard, what use is the standard?

> Secondly, if we do want to add an extra layer, having a resolution strategy
> does not have to include penalties - neither proposed ones nor the
> jurisdiction to impose ones.  If the RFC stopped at structuring how people
> can bring up issues and have them discussed and mediated, I doubt the RFC
> would be nearly as controversial as it is right now.

I think that the resolution strategy needs to have some sort of
penalty, up to and including removal from the project. Otherwise
what's the point of the resolution strategy? The worst thing we can do
is put up a resolution path that people just say "so? why should I
care?".

> The problems begin as soon as we try to create some sort of a
> mini-judicial-body, that has substantial powers,  governs based on loosely
> written rules, has zero tools and experience in getting to the bottom of
> things or determining the truth between two or more quarrelling parties.
> Thinking we can do that when we failed agreeing on infinitely simpler things
> is remarkably optimistic.

I'm not saying the current team I have proposed is good. I'm not
saying we need to be firm with it.

However, I think time and time again it's been proven that the court
of public opinion is a poor judge of these types of situations. The
recent edits that I have been making to the RFC reflect the reduction
in power of the team significantly. What I do want to keep is a safe
and private place for these resolutions to occur in.

In extremely significant cases decisions will need to be public, but
with a private team like this at least the information gathering step
can be done in a non-biased manner with a team.

> I disagree we NEED to do something.  PHP is not in a situation where it's in
> an absolute need of a CoC, and the fact it's thriving without one and that
> nobody appears to be coming up with examples as to why we must have one
> beyond future-proofing attests to that.  Yes, it's not perfect - but as Stas
> said, that RFC isn't a magic wand that would make it perfect.  That said, I
> think adopting a CoC is a good idea, much like I teach my daughters what's
> right and what's wrong without telling them what would happen if they don't
> follow my guidance.  Whenever I have to resort to penalties (which I'm happy
> to say rarely happens) - I've failed, and I virtually always regret it.

I don't believe we literally need to do something in the sense that
the project will die if we don't. With that said, I do believe that
adopting the right one will do a lot of good for the project and
community. So it's not a life or death need, I would say it's
something we should definitely try to do

Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

[Anthony Ferrara]

Stas,

On Tue, Jan 5, 2016 at 11:57 PM, Stanislav Malyshev  wrote:
> Hi!
>
>> In response to significant feedback here and elsewhere, I have
>> expanded the text of the RFC significantly. It now includes the text
>> of the Contributor Covenant 1.3.0 as well as including verbage about
>> updating it requiring an RFC.
>
> Thanks for improving the RFC. It is already much better than the initial
> variant, though I think more improvement is needed. As I wrote in
> previous emails, I'd like mode of what we want than what we hate. We
> already seen example from Drupal, here's one from Python:
>
> https://wiki.python.org/psf/CodeOfConduct
>
> I agree with having specific point of contact to turn to is beneficial
> and it should probably be featured on the same page as the text above. I
> am not sure I understand why list should be unarchived - while I see why
> *public* archive is not good, why not have private archive accessible to
> the members? After all, any member can archive all the emails anyway
> (and people with accounts like gmail probably routinely keep mails for
> years without deleting them). But having the established one avoids the
> situation where there's a problem with one member of the list and it
> turns to "she said, he said" situation with no proof of anything.
>
>> I included a vote requirement for course of actions of 4/5 of the CoC team.
>
> Good!
>
> Additionally, I would propose naming this team something like Mediation
> Team or Conflict Resolution Team, to emphasize that its primary role to
> find the best resolution of issues and not to bash people over the head
> with codes. Bikeshedding on the name along these lines is welcome :)

Yeah, that sounds completely fair. Plus it puts the focus on
resolution rather than punishment. I like that. I'll update the RFC
shortly.

>> This Code of Conduct applies both within project spaces and in public
> spaces when an individual is representing the project or its community.
>
> I think this is way too broad. "individual is representing the project
> or its community" can be construed to mean basically anything - if a
> person is known in the community, any of their actions, even without
> relation to the community functions, can always be construed as
> "representing", especially by people with an ax to grind. We'd get
> people complaining "how could prominent member of this project vote for
> that vile politician X" and "how could prominent member of this
> community support that awful law Y" and we definitely not want to go there.

It is broad for a reason. If harassment that's obviously connected
with the project (it would need to be obviously connected) happens
off-list, that's still problematic. I think limiting the scope to just
the project territories is dangerous as it provides too easy of a way
for members to cause problems with no resolution possible.

>> Process For Incidents
>
> I think the process should be amended to emphasize that the first course
> of action for the team should be to try and find amicable resolution of
> the issue (I imagine there are many established mediation techniques
> that can be applied and referenced, we're not exactly pioneers here :)
> and only when it proves futile (or misconduct is so egregious that it is
> obvious it is too late for mediation) the team would take further
> action. I.e. one does not need a vote to help diffuse the conflict.

Yeah, that's completely fair and worth while. I'll look at rewording
that after talking with the Drupal CoC people.

>> I also included content about the "Reasonable Person Test", explicitly
>> stating that it shall be assumed that both parties are acting as
>> reasonable people until proven otherwise by significant evidence. It
>
> That is good. I think the principle of assuming good faith leads to
> better results.
>
>> I also made it explicit that potential actions should be a last
>> resort, and that the CoC team should make every reasonable attempt to
>> defuse the situation without having to resort to "punishment".
>
> Excellent!
>
>> Either party may appeal an action by raising the concern to
> intern...@php.net.
>
> That would be impossible if one of the parties is banned from internals.

Unless we lift that ban just for the appeal. Meaning that the banned
individual requests an appeal, so they are unbanned for that single
thread until it is resolved...

>> All incidents are to be kept in the strictest form of confidentiality
>
> I still think the secrecy bias is unhealthy. I remember how much
> controversy was produces by the supposedly private discussions of
> certain technical questions and RFCs. Imagine how much more heat would
> be generated if the discussion in question has a conflict as a starting
> point. The potential for toxic suspicions and distrust is enormous.

The other side is far more serious though. Many MANY people avoid
coming forward about incidents because they are afraid they will be
labeled. Simply look at 

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Anthony Ferrara]

All,


On Wed, Jan 6, 2016 at 3:43 PM, François Laupretre  wrote:
> Le 06/01/2016 20:38, Ryan Pallas a écrit :
>>
>>
>> I agree, a conflict resolution document *and team* seems infinitely
>> better.
>> This team's job is to resolve things quietly and without further incident,
>> however if action may be required - its an open vote (as previously
>> suggested).
>
>
> Agreed. 'Don't be evil' is sufficient as a CoC. Anything we add to this will
> be redundant, ambiguous, and subject to interpretations.
>
> A small set of conflict resolution rules and a team of community-approved
> mediators is everything we need, IMHO.

I would like to hear from people who've had incidents before or have
been marginalized or harassed as to what is sufficient.

Anthony

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

[PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

[Anthony Ferrara]

All,

On Mon, Jan 4, 2016 at 4:06 PM, Anthony Ferrara <ircmax...@gmail.com> wrote:
> Hey all,
>
> I have created a new RFC for the PHP Project to adopt the Contributor
> Covenant as the official Code of Conduct for the project
>
> https://wiki.php.net/rfc/adopt-code-of-conduct
>
> Let me know what you think or if there are any concerns
>
> Thanks
>
> Anthony

In response to significant feedback here and elsewhere, I have
expanded the text of the RFC significantly. It now includes the text
of the Contributor Covenant 1.3.0 as well as including verbage about
updating it requiring an RFC.

I included a vote requirement for course of actions of 4/5 of the CoC team.

I also included content about the "Reasonable Person Test", explicitly
stating that it shall be assumed that both parties are acting as
reasonable people until proven otherwise by significant evidence. It
also stipulates that reporting an incident does not excuse someone
from the CoC (meaning victims are still bound to follow it, and are
not excused from proper behavior because of a violation).

I also made it explicit that potential actions should be a last
resort, and that the CoC team should make every reasonable attempt to
defuse the situation without having to resort to "punishment".

I also removed the ability to remove commit karma from the team,
instead including that in the "ban" category (meaning that the CoC
team is no longer allowed to remove commit karma long-term without the
action of internals@)

Additionally, I added a line specifying that bans (temporary or
permanent) should only be used in egregious cases.

I added a section on transparency, Conflict of Interest (though this
needs expanding) and accountability (giving internals@ the ability to
"overturn" any action by the CoC team with a vote of 50%+1). I also
made it explicit that accused people have a right to confidentiality
as long as no action is taken by the team.

I also added a section on appeals.

Those are the changes to the RFC as it stands. Please review them.



As to the comments in this thread, I won't reply to every one, but
here are a few points I'd like to make.

It's been mentioned that we may want to adopt a CoC, but it shouldn't
"have teeth". I disagree here, as without an enforcement mechanism it
basically is no different from where we are at today. Saying we should
act reasonable is fine, but we need a method for what we are to do
when one of us acts unreasonably. Additionally, as has been stated,
requiring people to report publicly creates a barrier to entry. Many
people will simply chose to leave quietly rather than report publicly.
Simply look at the way people who speak out about harassment are
treated in public to understand why. The point of the CoC is to create
a safe place for everyone to contribute, not just those with thick
skin.

As to why the Contributor Covenant as opposed to another CoC or our
own custom one, there are two reasons for this. First, it's a standard
that's been adopted by a number of significant scale projects. Second,
it saves us from having to bikeshed over every single word of a CoC.
If there's another standard CoC that we should entertain, I'm happy to
look at it. But I do not believe that we should create our own.

As far as the conflict resolution process, that I am open to expanding
or retracting as much as practical. I do think it's important to have,
but would be happy to take advice from groups like Drupal who have
done this before.

To those that say this is a solution in search of a problem, it very
well may be. But that doesn't mean it isn't important to do. You could
say the same thing about smoke detectors. Even if you've never had a
fire, that doesn't mean it isn't good practice to install protection
from one. In this case, we simply do not know if or how many
contributors we may have lost due to incidents covered by a CoC. Even
if that number is 0, does that mean it's not worth installing one to
prevent it in the future?

Thanks,

Anthony

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Anthony Ferrara]

Rowan,

On Tue, Jan 5, 2016 at 2:16 PM, Rowan Collins  wrote:
> Paul M. Jones wrote on 05/01/2016 16:03:
>>
>> It's a*political*  action designed with a*political*  intent
>
>
> Please stop assuming that everybody has a hidden agenda at odds with their
> public statements, and claiming that you somehow know that the negative
> possibilities of this policy are deliberately in service of its secret aim,
> rather than unintended consequences of its stated aim.
>
> If you dislike the details of this proposal, that is fine, and you can
> explain what you don't like about it, and what you would prefer instead -
> e.g. a "be nice" policy without explicit teeth, or total anarchy and the
> right to insult, threaten, and bully whoever you choose because you honestly
> believe that "free speech" trumps all other moral and pragmatic
> considerations.
>
> Bear in mind you will be expected to defend that position, and that people
> have the right to disagree with you, and attempt to find common ground and
> compromises. That's how conversations work.
>
> If all you're doing is trolling the group because you think being rude on a
> thread about good conduct is funny, please go do it on 4chan or reddit or
> something.

Paul isn't trolling. He is simply passionate about it. While I do
believe he can be more constructive with how he interacts in this
specific thread, he definitely isn't trolling (trying to cause drama
for drama's sake). We should be careful about that term and use it
appropriately.

Anthony

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Anthony Ferrara]

Larry

>> I'll chime in on this, since you and I had a quite pleasant and
>> productive conversation last night.  I believe we agreed that the
>> original draft was over-focused on punitive measures and not enough on
>> low-impact mediation.
>>
>> I imagine, because I love all you guys (and gals), that the volume of
>> traffic to a response team would be low to begin with.  I further
>> imagine, since you're all such a great bunch of lads (and lasses),
>> that the vast majority of those complaints would be resolvable with
>> some gentle mediation.  That's a good focus for the CoC, and I would
>> love to bring us to that point.  (Sorry if you've already addressed
>> this Anthony, I haven't read your updates yet, it's been a busy
>> morning).
>>
>> I said it in a prior email, but I'll repeat it.  I see it like the
>> security@ list.  A place to send issues that don't necessarily bear
>> airing in public.  That's good for both the accuser AND the accused.
>> A tiny layer of discretion to ease what may be a tense issue.
>>
>> I don't, however, agree that the response team should be entirely
>> toothless.  As a *last resort*, a (no more than) 7 day ban to act as a
>> cooling off period isn't "vast sweeping powers", it's a band-aid for a
>> situation that's gotten out of control.  A situation that demands the
>> wider community's attention, because it's become unacceptable.  We can
>> define the limits of these powers (again I've said this in a previous
>> email).
>>
>> Worried about abuse of temp-bans?  Don't think a stringent requirement
>> of justification is enough?  How about the accuser must suffer an
>> equal ban?  By the time it's come to the point where action must be
>> taken, the problem has escalated to the point where privacy of the
>> accused won't be maintainable anyway (due to evidence requirements).
>> Turn the temp-ban into a cooling off period.  Because honestly, do we
>> have mustache twirling ne'er-do-wells? Or do we have passionate people
>> who get worked up into a lather and sometimes cross a line?
>>
>> As someone who has crossed that line more than once, I hope you'll
>> trust it's just the latter.
>>
>> -Sara
>
>
> I agree with Stas (previous email) that a bad CoC can backfire.  I'd go as
> far as saying that a bad CoC (either one that is so toothless as to be a lie
> or one that is so draconian that everyone lives in fear of it) is worse than
> no CoC at all.  That is, I think, the point of this discussion: Make sure
> that a CoC is adopted that is good and has a positive impact, not bad with a
> negative impact.
>
> Which is where I agree with Sara: A good CoC should be positive and focused
> on conflict-resolution, not on punitive measures.  So let's build a good
> conflict-resolution-oriented CoC and process rather than a
> ban-hammer-mechanism.  Also, recall that this is not a for-all-time
> definition.  CoCs can and should evolve over time, as should the process
> around them.
>
> Disclosure: I've been through Drupal's Community CoC, the DrupalCon CoC, and
> multiple rounds of CoC-esque discussion in a 20-year old online RPG club I
> used to help run.  I've been around this block more than once.
>
> Reference material:
>
> Drupal's Community CoC:
>
> https://www.drupal.org/dcoc
>
> was derived originally from the Ubuntu Community CoC:
>
> http://www.ubuntu.com/about/about-ubuntu/conduct
>
> The DrupalCon CoC was more contentious until it was rewritten to be more
> positive-oriented (less "we don't" and more "we do"):
>
> https://austin2014.drupal.org/code-of-conduct.html
>
> The main author of the DrupalCon CoC, George DeMet, pointed me at the Django
> CoC as another good model:
>
> https://www.djangoproject.com/conduct/
>
> Sara, Stas, Anthony, are you open to talking with George? (Disclosure:
> Besides being on the Drupal CWG, George is also my boss. )


Definitely! I overall like Drupals CoC (I looked at it in response to
this thread). Thanks for offering to set something up!

Anthony

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

Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

[Anthony Ferrara]

Zeev,

On Tue, Jan 5, 2016 at 3:10 PM, Zeev Suraski <z...@zend.com> wrote:
>> -Original Message-----
>> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
>> Sent: Tuesday, January 05, 2016 6:16 PM
>> To: internals@lists.php.net
>> Subject: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct
>>
>> As to the comments in this thread, I won't reply to every one, but here
>> are a
>> few points I'd like to make.
>
> Anthony,
>
> Thanks - I think the new draft looks much better and addresses much of my
> feedback.  I still think it puts too much emphasis on the mechanics and
> punitive actions, see below.

Awesome. It very well may be too hard on the punitive actions. A
balance is surely the correct approach, I was more talking against
lack of any "recourse". But am very much open to tweaking the level
and tone.

>>
>> It's been mentioned that we may want to adopt a CoC, but it shouldn't
>> "have teeth". I disagree here, as without an enforcement mechanism it
>> basically is no different from where we are at today.
>
> I think it's actually very different.  Today we have no CoC.  Stating a
> direction, a vision for the community - can go a very long way.  To
> illustrate, I suspect most of us are law-abiding citizens not because we're
> afraid of being thrown to jail - but rather, because we value the rule of
> law and know that abiding the law is the Right Thing to do.  If we simply
> adopt a CoC without adding teeth to it, we'd certainly not be the first
> project to do so.

True, but as Larry said, either side is problematic. Too loose of a
CoC with no enforcement and nothing really was changed from today
considering we already have the post that Rasmus made 6-7 years ago.
Sure, it's something to rally behind, but it doesn't really solve any
problems. The problem is that there's no safe way for people to get
help. The CoC is part of the solution to that, but not the only one.

>> Saying we should act
>> reasonable is fine, but we need a method for what we are to do when one of
>> us acts unreasonably.  Additionally, as has been stated, requiring people
>> to
>> report publicly creates a barrier to entry. Many people will simply chose
>> to
>> leave quietly rather than report publicly.
>> Simply look at the way people who speak out about harassment are treated
>> in public to understand why. The point of the CoC is to create a safe
>> place
>> for everyone to contribute, not just those with thick skin.
>
> My main concern is/was that we're venturing into areas where we have
> absolutely no experience and completely inadequate training.  We are not
> legislators nor lawyers;  We've demonstrated more than once that we're not
> very good at establishing 'written law' for far simpler and non-ambiguous
> things, failing to predict all possible scenarios of the future.  The fact
> we need to borrow definitions from Criminal Law should be an indicator that
> we're probably venturing in the wrong direction here.  The system
> responsible for implementing the law, as we all know, is complex and with
> countless checks and balances - and as I think we all know, it is also
> subjective, completely open for interpretation and with a very strong human
> element - and consequently frequently fails.  My concern is that we're
> trying to sketch a simplistic system which would fail us in unpredictable
> ways in the future, when the rubber meets the road.
>
> And with all that said, it seems to be much less of an issue with the
> updated RFC, given the reduced power of the CoC team and the changed
> 'spirit' of it.  I do need to review the RFC more closely though.

Yeah, I never intended it to be a "law document". The main reason for
the CoC Team was to respect confidentiality and not require full
public disclosure of all incidents (which will drive people away). The
exact tone and language definitely still needs work.

The main reason for posting it soon was to start the conversation, not
finish it. In fact, I can see a very real world where the majority of
the policies around the CoC team are replaced with
https://www.drupal.org/conflict-resolution or something similar. The
presence of the team is the important part to me, not the strength or
precise process.

>> As to why the Contributor Covenant as opposed to another CoC or our own
>> custom one, there are two reasons for this. First, it's a standard that's
>> been
>> adopted by a number of significant scale projects. Second, it saves us
>> from
>> having to bikeshed over every single word of a CoC.
>> If there's another standard CoC that we should entertain, I'm happy to
>> look
>> at it. But I do not believe that we should create our own.
>

Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

[Anthony Ferrara]

Chase,

On Tue, Jan 5, 2016 at 4:51 PM, Chase Peeler  wrote:
> While overall I tend to agree with Paul on the concept of a CoC, I don't
> think that precludes the ability to offer suggestions. It's to everyone's
> advantage to make sure that if we do adopt a CoC, we adopt the best one
> possible.
>
> Obviously one of the biggest fears is unjust treatment of the accused. The
> thing that is most likely to lead to that would be pre-existing personal
> biases towards the accused (or in favor of the accuser) by a member of the
> committee. Why not require that at least one member come from outside the
> PHP community all together. I don't know how feasible that really is, but
> assuming it is, it's probably the best way to ensure that there is at least
> one person that is more likely to be as unbiased as possible.
>
> That member could be voted on like all the other members, or, due to the
> fact that voters are hopefully less familiar with such candidates, be
> appointed by the elected members of the committee.
>
> Obviously it's not perfect and still allows the possibility of abuse, but
> you reach the point where such abuses almost require a coordinated
> conspiracy.

Thanks for the suggestion!

So that would mean there would be 3 "required seats":

 * PHP-SRC karma
 * PHP-DOCs karma
 * no karma

and then 2 "arbitrary" seats.

I like the idea overall, but would very much like to hear other's
feedback prior to adding that.

Thanks!

Anthony

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

[PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Anthony Ferrara]

Hey all,

I have created a new RFC for the PHP Project to adopt the Contributor
Covenant as the official Code of Conduct for the project

https://wiki.php.net/rfc/adopt-code-of-conduct

Let me know what you think or if there are any concerns

Thanks

Anthony

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Anthony Ferrara]

Adam,

On Mon, Jan 4, 2016 at 4:41 PM, Adam Harvey <ahar...@php.net> wrote:
> On 4 January 2016 at 13:06, Anthony Ferrara <ircmax...@gmail.com> wrote:
>> I have created a new RFC for the PHP Project to adopt the Contributor
>> Covenant as the official Code of Conduct for the project
>>
>> https://wiki.php.net/rfc/adopt-code-of-conduct
>
> I am definitely pro-this. Good thinking!
>
>> Let me know what you think or if there are any concerns
>
> Although it's not required by our voting process, I think it might be
> a good idea to require more than a basic majority for adopting this.
> It feels like something we need broad buy-in on.
>
> Thoughts?

Yeah, I definitely see that point, especially as it's giving a small
group of people power. I've made the flip to 2/3 majority.

Anthony

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

Re: [PHP-DEV] RFC: PHP 5.6 Support Timeline

[Anthony Ferrara]

Zeev,

On Tue, Dec 8, 2015 at 10:14 AM, Zeev Suraski  wrote:
> Following the initial discussion, I prepared an RFC that proposes to extend
> the support periods for PHP 5.6:
>
>
>
> https://wiki.php.net/rfc/php56timeline
>
>
>
> Thanks to Ferenc Kovacs and David Zuelke for reviewing it for any glaring
> omissions.
>
>
>
> Let the discussion continue…

I'd prefer it if the RFC took a stance and made a recommendation to
one of the options. That way the discussion could be more guided
around the stance rather than simply generic. And also it makes the
votes easier to understand as it's more of a "yes/no" rather than
multiple options.

Overall, I fall into the 1 year maintenance, 2 year security camp.
That would put 5.6 EOL when 7.3 is out (approximately).

Thanks for putting it together.

Thanks.

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

Re: [PHP-DEV] RFC: PHP 5.6 Support Timeline

[Anthony Ferrara]

Zeev,

On Tue, Dec 8, 2015 at 1:15 PM, Zeev Suraski <z...@zend.com> wrote:
>> -Original Message-----
>> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
>> Sent: Tuesday, December 08, 2015 6:09 PM
>> To: Zeev Suraski
>> Cc: PHP internals
>> Subject: Re: [PHP-DEV] RFC: PHP 5.6 Support Timeline
>>
>> Zeev,
>>
>> On Tue, Dec 8, 2015 at 10:14 AM, Zeev Suraski <z...@zend.com> wrote:
>> > Following the initial discussion, I prepared an RFC that proposes to
>> > extend the support periods for PHP 5.6:
>> >
>> >
>> >
>> > https://wiki.php.net/rfc/php56timeline
>> >
>> >
>> >
>> > Thanks to Ferenc Kovacs and David Zuelke for reviewing it for any
>> > glaring omissions.
>> >
>> >
>> >
>> > Let the discussion continue…
>>
>> I'd prefer it if the RFC took a stance and made a recommendation to one of
>> the options.
>
> It does, perhaps not in a strong enough way:
> "Further, given the 5.6 -> 7.0 upgrade is more difficult and time
> consuming - our recommendation is option #1".
>
> I shuffled things around a bit to make it clearer.  Let me know if that
> answers your concern.

Looks much better. Thank you.

I still would rather see one vote (I have a thing against multiple
vote options in general). If it gets denied, then we could do a
different RFC with a different option.

But having the stance being recommended is a good step forward.

Thanks

Anthony

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

Re: [PHP-DEV] Namespaces

[Anthony Ferrara]

Scott,

On Fri, Dec 4, 2015 at 11:26 AM, Scott Arciszewski  wrote:
> Hi,
>
> It has been brought to my attention that my consistent use of \ prefixing
> of global functions is an eyesore, but I've got a simple little PoC that
> shows why I do it, and now I'm wondering if the behavior I'm working around
> should qualify as a PHP bug?
>
> https://3v4l.org/po925
>
> Scott Arciszewski
> Chief Development Officer
> Paragon Initiative Enterprises 

It's not a bug. It's explicit. The `\` prefix says it's a global
function. The non-prefixed looks in the current namespace and then
falls back to global.

Also, in PHP 5.6+ you can do something slightly different to achieve
the same result: use function.

namespace Foo {
use function random_int;
var_dump(random_int(1, 100));
var_dump(\random_int(1, 100));
}

That will always behave the same no matter if someone defines a
namespace-specific random_int function, it will always use the global
version.

https://3v4l.org/cR6Gg

This actually opens a pretty interesting edge-case, where you can
define a function in the namespace and use the global one without
needing a "\".

namespace Foo {
use function strlen;
function strlen(string $str) : int {
return strlen($str) + 1;
}
}

That actually is not recursive. This is a bit non-obvious, but
completely follows the rules set forth. So I don't think there's a bug
(though we may want to raise a notice in that collision case)...

Anthony

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

Re: [PHP-DEV] Scalar Type Declaration Syntax Weirdness

[Anthony Ferrara]

Sebastian,

On Tue, Nov 24, 2015 at 10:10 AM, Sebastian Bergmann  wrote:
>  The following is currently valid PHP 7 code
>
>function a(\int $i) {}
>
>  Is it intentional that the \ in front of the "int" is allowed? IMHO, this
>  confusing notation must not be allowed.

Yeah, that is a problem. We should fix that prior to gold. I'll take a
peak at it when I get some time, but if someone else has a few minutes
and wants to tackle it go for it.

Anthony

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

Re: [PHP-DEV] INDRECT in arrays causes count() to become unpredictable

[Anthony Ferrara]

Zeev and all,

On Mon, Nov 23, 2015 at 9:05 AM, Zeev Suraski  wrote:
>
>
>> On 23 בנוב׳ 2015, at 14:04, Joe Watkins  wrote:
>>
>>
>> No one is expecting 0.0 or any version to be bug free, but the simplicity of 
>> the fix says nothing about the seriousness of the bug. I think it quite 
>> serious _because_ we are a few days from GA, had this been found a month ago 
>> it wouldn't seem so serious.
>>
>
> No, but both the seriousness of the bug AND the simplicity of the fix sit 
> squarely outside any sort of "critical" definition.

Perhaps, except that this bug was known by engine maintainers for
months. It actually took one of them saying it outright in a chat room
for me to be like "WTFBBQ" and raising this thread.

That seriously shakes confidence in stability. What else is known but
not common knowledge? What else is not known? etc.

> The bug simply has the unfortunate connotation of being associated with 
> arrays, but is not - it's only about count()ing symbol tables.  The fix 
> itself is very localized too and was peer reviewed, so I don't feel as if 
> we'd be living on the edge of we'd be releasing without an extra RC.
>
> My main concern is that of we're treating this issue as a semi blocker - it's 
> almost unthinkable we won't find something of similar (small) magnitude in 
> the next seven days.  That's my only concern with releasing next week,m.  
> Would people here again demand to delay, even if the impact is very limited - 
> as is the case with this count() issue?  If it wasn't for that concern, I'd 
> probably be in favor of delaying.

The main concern of many of us is that many people here seem to be
demonstrating a cavalier attitude around what constitutes a .0 release
(a stable release). Of course it's going to have bugs, but it **MUST**
be as stable as possible. The attitude by many here of "eih, it won't
be bug free anyway, so who cares" is poison.

If we delay further, we lose nothing. It's not like shipping a week
later is going to cost anyone anything. But shipping a broken version
WILL cost us a lot. We've been really good the past several releases
(5.4, 5.5, 5.6) about shipping stable versions day 1. If we break that
trend, it will shake faith. It will cost us far more.

Rasmus,

> I think this was mostly a PR failure on my part actually. If I/we are a bit 
> more careful about how we handle similar issues and the people lurking with 
> itchy Twitter trigger fingers would spend a bit more time looking into the 
> details we should all be able to get along and get a good launch with no 
> controversy on Dec.3.

Sorry, but when you make a statement like:

> Nobody is going to take a .0.0 and push it straight to production.

THAT is more than a PR failure. That's a perspective failure.

> And it is not going to part of any sort of LTS distro either. It's not like 
> LTS distros don't pick up point releases.

They don't. Debian squeeze is still pinned on 5.3.3. This causes me
major headaches since they didn't backport serious security features,
leading to problems today. Saying "they pick up point releases" may be
true for some, but the history is there that has caused MANY open
source projects a TON of pain. So it's definitely not something to
brush off.

I'm less concerned by the specific issue here than by the 2 facts that
surround it: It was known by engine maintainers for months, and the
cavalier attitude around what defines "stable". Both of these are far
more critical and worth delaying to "get right" than this particular
"bug" is...

Anthony

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

Re: [PHP-DEV] INDRECT in arrays causes count() to become unpredictable

[Anthony Ferrara]

Zeev,

On Mon, Nov 23, 2015 at 9:43 AM, Zeev Suraski <z...@zend.com> wrote:
>
>
>> On 23 בנוב׳ 2015, at 15:21, Anthony Ferrara <ircmax...@gmail.com> wrote:
>>
>> Zeev and all,
>>
>>> On Mon, Nov 23, 2015 at 9:05 AM, Zeev Suraski <z...@zend.com> wrote:
>>>
>>> No, but both the seriousness of the bug AND the simplicity of the fix sit 
>>> squarely outside any sort of "critical" definition.
>>
>> Perhaps, except that this bug was known by engine maintainers for
>> months. It actually took one of them saying it outright in a chat room
>> for me to be like "WTFBBQ" and raising this thread.
>
> A conspiracy to hide a not-very-important bug that took minutes to fix would 
> be a bit awkward.  I have no idea who knew about it, but even if someone did, 
> I can only imagine that the reason it wasn't disclosed was that they didn't 
> think much of it.  Whomever it was can shed light on this.

Conspiracy is a loaded term and not at all what I meant nor said. It
was known. And yes, I'm sure they didn't think much of it. That
doesn't mean that there aren't other cases where individuals made
tradeoffs that they feel are "worth it" but that others may not.
Considering this was definitely known in advance.

Causing one person to say "IS_INDIRECT is really kinda crappy, and
likely has many latent bugs. It sucks that things like count($array)
are no longer reliable but are now an upper-estimate" (SIC). That was
how I originally found out.

Heck Dmitry even admits it when he mentions that they had to work
around this very issue with serialize().

I'm not pointing fingers here. I'm not even saying people acted in bad
faith or anything remotely like that. I'm just saying that how many
other issues like this are waiting for us to find. Where people knew
about it but chose not to act because they "didn't think it was a big
deal" or "it wasn't worth the performance hit". And that's fine. But
at the same time it's concerning. And that's the point I was trying to
get across.

> Either way, looks like we're creating some really negative vibes, questioning 
> the very people who we owe gratitude for creating PHP 7, and in general, 
> making an elephant out of a mouse.  Let's go back to elePHPants.

Who's creating negative vibes? We're pointing out that we need to be
more clear around the definition of stable and the expectations for a
".0" release. If that's not being "grateful", then you're right we
shouldn't be grateful. We should be professional enough to talk about
our outcomes separate from the effort that got us there. We all are
incredibly grateful to everyone that put forth effort. But that
doesn't mean we should make compromises "just to ship something".

Anthony

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

Re: [PHP-DEV] INDRECT in arrays causes count() to become unpredictable

[Anthony Ferrara]

Zeev,

On Sat, Nov 21, 2015 at 11:52 PM, Zeev Suraski <z...@zend.com> wrote:
>
>> On 22 בנוב׳ 2015, at 0:47, Anthony Ferrara <ircmax...@gmail.com> wrote:
>>
>> I think this is significant enough to be a blocker to gold and that we
>> should fix it prior to release.
>>
>> Thoughts?
>>
>
> IMHO, unless we think fixing this would require breaking binary compatibility 
> (which I don't think is the case) - this shouldn't block 7.0.0.  7.0.0 is a 
> lot more about getting people to start paying attention to 7.0 and start 
> testing their codebase against it - finding both the incompatibilities in 
> their code and, undoubtedly - the bugs we failed to find.  I wish we could 
> say this would be the last issue we find in 7.0, but I think we can all agree 
> it's wishful thinking...

Consider that Distros may very well pick whatever we call stable for
LTS releases. Meaning that non-critical (crash/security) bugs that we
miss may wind up living on for a VERY long time. If we don't intend .0
to be stable, then what's the point of versioning in the first place?

Xinchen,

Very interesting on the fix. I do think it's important for this to
land with 7, but at least we can have the discussion.

Thanks!!!

Anthony

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

[PHP-DEV] INDRECT in arrays causes count() to become unpredictable

[Anthony Ferrara]

All,

It appears that in our efforts to optimize PHP 7 we've introduced an
inconsistency into array handling. This is demonstrated by this
script: https://3v4l.org/hVcAB

$a = 1;
unset($a);
var_dump(count($GLOBALS), $GLOBALS);

The result is that the count doesn't match the contents of the array.

It also affects objects casted to arrays in certain cases.

Here, the array has 1 element, but should have 0. Trying to access the
"1" element "a" results in a notice.

This means that the count is incorrect. This is due to the fact that
the "a" element follows an IS_INDIRECT type pointing to the other
symbol table.

A potential solution would be to make count() an O(n) operation in the
case that the hashtable is a symbol table or if it has INDIRECT
elements. Meaning that we'd compute the real count at runtime.

This obviously has performance ramifications, but we shouldn't
sacrifice consistency and behavior for performance IMHO. Especially
when it comes to core data structures.

I think this is significant enough to be a blocker to gold and that we
should fix it prior to release.

Thoughts?

Anthony

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

Re: [PHP-DEV] Immutable modifier

[Anthony Ferrara]

Chris,

On Mon, Nov 16, 2015 at 4:15 AM, Chris Riley  wrote:
> Hi,
>
> There has been a lot of interest recently (eg psr-7) in immutable data. I'm
> considering putting an RFC together to add language support for immutables:
>
> immutable class Foo {
> public $bar;
> public function __construct($bar) {
> $this->bar = $bar;
> }
> }
>
> Immutable on a class declaration makes all (maybe only public?) properties
> of the class immutable after construct; assigning to a property would
> result in a Fatal error.
>
> class Foo {
> public $bar;
> immutable public $baz;
> }
>
> Immutable on a property makes the property immutable once it takes on a
> none null value. Attempts to modify the property after this results in a
> fatal error.

Beyond syntax/whatever, I would suggest finding a method to do it
internally. That's going to be the biggest problem in my experience
(finding some way of doing it efficiently)...

Anthony

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

Re: [PHP-DEV] Re: [PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Remove arc4random: ext/standard/config.m4 ext/standard/random.c

[Anthony Ferrara]

Tom,

> 3. arc4random puts a generator in the user process.
>
> This is much more controversial. Some people (Anthony F. for one and myself
> until recently) argue that a generator algorithm in the user process
> degrades security. It must in any case be downstream of the kernel source
> and therefore cannot compensate for any problems in using kernel randomness.
> Moreover, it adds another point of failure (a place where there might be
> bugs, like OpenSSL's RNG bugs). And finally, since the downstream generator
> is in the user process rather than protected kernel memory, it's easier for
> an attacker to learn the generator's state and thus predict future outputs.
>
> Others, including Dan Bernstein[1] and the OpenBSD crowd[2], argue that the
> later is theoretical rather than a practical vulnerability because if an
> attacker can read your memory then your crypto system is a total fail
> regardless where you get random numbers from.

There is one important nuance here though. If an attacker can read
memory they they can compromise anything currently in memory for the
application. Things that have since been freed (such as tokens and
secrets generated from prior requests) are typically safe. However,
using a userland RNG, that's not necessarily true unless a reseed
(stir) event happened between them. So you do lose some practical
forward security in that things that otherwise may not have been
leaked may be leaked. So I would still consider it a practical
vulnerability.

And an attacker reading memory is only game over if they can control
how and when that memory is read. It's a fail in any case, but if the
exploit only allows them to ever see memory from their request, it's a
lot less damaging than if they can see other's requests on the system.
It's still quite bad, but there's definitely a difference.

Thanks again for the discussion

Anthony

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

Re: [PHP-DEV] Password_hash salt generation refactor

[Anthony Ferrara]

All,

On Tue, Oct 20, 2015 at 11:35 PM, Anatol Belski <anatol@belski.net> wrote:
> Hi Anthony,
>
>> -Original Message-
>> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
>> Sent: Monday, October 19, 2015 1:00 AM
>> To: internals@lists.php.net
>> Subject: [PHP-DEV] Password_hash salt generation refactor
>>
>> All,
>>
>> With PHP 7 comes random_bytes and random_int. This duplicates some of
>> the logic internally that password_hash uses to generate its salt.
>>
>> I would like to refactor this to unify generation. I've opened a PR against
>> master: https://github.com/php/php-src/pull/1585
>>
>> I don't feel comfortable pulling against 7 this far into RC status.
>> Perhaps wait until after it goes gold? Or should this target 7.1? It's not a 
>> big
>> deal in either direction. Though it does add a side-effect, where if it can't
>> gather enough entropy it will throw an exception and return failure (where
>> prior it would simply make a "best effort".
>>
>> Thoughts?
>>
> As much as it could be an improvement of the password_hash(), one would 
> better avoid any behavior change at this stage. I was thinking about it and 
> came to an idea that maybe could work for 7.0 - one should just make 
> php_random_bytes() that side effect free.
>
> Could php_random_bytes() be extended with a flag that would tell exceptions 
> to pass? Or maybe exceptions could be moved out from the php_random_bytes() 
> and thrown directly in the new functions that was undergoing the RFC but not 
> password_hash() ? I'd be actually for the second variant.
>
> That ways FAILURE would be returned, but a decision about what to do about it 
> would be made outside. IMHO it were also useful as the API is intended to be 
> exported. So for the cases where php_random_bytes() came to use as a library 
> function outside immediate PHP userspace (for example in SAPI), it should not 
> throw exceptions from itself.
>
> Do this suggestions sound eligible?


I have created a PR for this: https://github.com/php/php-src/pull/1614

It changes the public API of the internal php_random_bytes function to
have a third "should_throw" parameter, as well as defining two macros:
php_random_bytes_throw(dest, len) and php_random_bytes_silent(dest,
len).

If this looks acceptable, it can be pulled into 7.0, and then the move
for password_hash can be done at a later date.

Thanks

Anthony

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

Re: [PHP-DEV] PHP 7.0.0RC6 is available

[Anthony Ferrara]

Shouldn't gold wait for fixes on critical and reproducible bugs? Like
https://bugs.php.net/bug.php?id=70805 which is currently blocking
Drupal 8 from supporting PHP 7.0...

On Thu, Oct 29, 2015 at 8:15 AM,   wrote:
> Hi,
>
> The sixth release candidate for 7.0.0 was just released and can be
> downloaded from:
>
> https://downloads.php.net/~ab/
>
> The Windows binaries are available at
>
> http://windows.php.net/qa/
>
> This release contains fixes for 10 reported bugs and marks the end of the
> pre-release circle.
>
> Please test it carefully, and report any bugs in the bug system.
> The 7.0.0 general availability (GA) release is going to be tagged on
> November 10th and issued on November 12th.
>
>
> Below is the verification information for the downloads:
>
> php-7.0.0RC6.tar.bz2
> SHA256 hash:
> d36b768d0ae9cc8b8c7c259949f60edca7946cfb5956d248921cb2100ea81361
> PGP signature:
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEcBAABAgAGBQJWL9B5AAoJELyqMOqcDVdj45YIALAYFT/D4ffraN2WHo7enntI
> IpEW+O6EPIFqmCwpFIzf7FC+iNizLUe/bvsktnEpo8Ctn4UiYiPIv+vL37zYgRmu
> RtTF1EhxWe8UF2iEBvZ02wk1nMFSByM1J+ZhnKnNyXwXUsqv4k1ogdH+b1w00tan
> PLU0Sw+0rLUR0l5m4oIXUplm1jmsianUCTTHnQi6VrB5S/ypQfAYqjbT9HyB+Xxi
> mEc9HiS95rsfJeADbz4NsJ+wR1udd9OBcEtIqmn41GW/NoUty9fJoIA+89MU4RKo
> J9aF7rIY7OhyBVd7fSNMp30+1j+5Af4E+/5grzGf2CJLBNE7if5qsxWXa21EiwY=
> =D6ER
> -END PGP SIGNATURE-
>
>
> php-7.0.0RC6.tar.gz
> SHA256 hash:
> 39a050583803ead17438d82f70b954c38dd6d445e7318ec4f7e8a411f7a6e772
> PGP signature:
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEcBAABAgAGBQJWL9CAAAoJELyqMOqcDVdjNXAH/32FSSu+5qLqyLx4fYkP5yvn
> EhlBHp4eqSDUSPTu6Lb52hkdMZJMwoUBgvV/qyOHsF90tf9iseYnMfz/zMtAP494
> dbE4VcCXroSEC49Ra7hqfUnELusO0NcqSl3/Dw/73QwOJG4O96wojR8hj1MdviLE
> k9caOGM2dU2dpJdRv4TJtneRk7vMALef+TbmGT7fbzAwH0U6OETZ08/jMjd9Ivpa
> Z0dSnU5/F7hqFPrGStMf6VE/zdPEKXu6iRsSrMBZYu8N7jPsz9nLSStXgyPCnyWv
> QJ9hCGRfNX9bs1MzFNT0fGFpY57GL32I+fz0T2PZwlqxklKHktj0E6+b8J2p1rU=
> =zEOK
> -END PGP SIGNATURE-
>
>
> php-7.0.0RC6.tar.xz
> SHA256 hash:
> c88ac8ec45f5c1a3f0a7254d4e6da520daf590147cafd6a047f91b8d9f2a1bd7
> PGP signature:
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEcBAABAgAGBQJWL9CDAAoJELyqMOqcDVdjuZAIAKRH7UeykmeQaRo1KA/HoICK
> y8TW3j9r/he6wSjqlpJl/LHZoB3lgWE/W/zOsdvC/2hpcl5jQtbh7Fe/p3zZzpdT
> dUkNVEV1rEZeX8QIuKhLfhNWIzdAEdRk90POmqvDli/K0taLq1Hq7sfrbS2KHlHK
> gWqQDhmoafMT2eRyO0KB0RJaZbcuKzybwsbLKCsL1jvT95CWpgvw3wosxzLWoH01
> /g/o42aTiGgTyLIOERjzPIO5nGpzGverRgMCVwbgJu40k1xIp6a92zcxtWtdZN4s
> 6TRLwbJfnw7OQjRAtf9P6JJd2r2ySrFEzc5J9x4P0tFlG6lhqTh4AXDqye0nk2w=
> =yEp1
> -END PGP SIGNATURE-
>
> Regards,
> Kalle Sommer Nielsen, Anatol Belski and Ferenc Kovacs
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

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

Re: [PHP-DEV] [VOTE] Void Return Type RFC

[Anthony Ferrara]

Dan,

On Thu, Oct 29, 2015 at 9:22 AM, Dan Ackroyd  wrote:
> Pedro, your email client snipped off the internals CC
>
> On 29 October 2015 at 13:11, Pedro Cordeiro  wrote:
>> If that callback is actually a void function, then using its return value IS
>> an error. The same way using a variable you're not sure exists, using a
>> return value that you don't know is there is prone to errors.
>>
>> The weird thing is disallowing even a null return while still silently using
>> null as the return value. It makes no sense.
>>
>
> As I said, the current behaviour of PHP of returning a value for all
> functions is awesome and eliminates a whole class of errors.
>
> Adding a pseudo-type that makes people want to break this behaviour is not 
> good.
>

That's not what's happening here though. What's happening is that it's
giving the author the ability to say "this function doesn't return
anything meaningful". The fact that void gets "converted" to null when
you "use" the function isn't a wtf, it's a language rule. Just like C
gives you undefined behavior (Though technically you can do it), just
like Java gives Class, TypeScript gives you undefined or null
(both pass void).

As far as "why not just use null", first off, what other language does
that? Many have void return types. I'm not aware of a single one that
uses "null" as its "void" return type. I think the bigger WTF would be
breaking away from the trend of every other language using "void"
rather than saying "well, when you assign a void function to a var you
get null". I think the latter is quite clear and easy to explain in
documentation. The former would be a bit more of a WTF, especially
from others who come from (or go to) other languages.

Anthony

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

[PHP-DEV] Password_hash salt generation refactor

[Anthony Ferrara]

All,

With PHP 7 comes random_bytes and random_int. This duplicates some of
the logic internally that password_hash uses to generate its salt.

I would like to refactor this to unify generation. I've opened a PR
against master: https://github.com/php/php-src/pull/1585

I don't feel comfortable pulling against 7 this far into RC status.
Perhaps wait until after it goes gold? Or should this target 7.1? It's
not a big deal in either direction. Though it does add a side-effect,
where if it can't gather enough entropy it will throw an exception and
return failure (where prior it would simply make a "best effort".

Thoughts?

Anthony

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

Re: [PHP-DEV] Re: [RFC] Void Return Type (v0.2, reöpening)

[Anthony Ferrara]

Robert,

> You write in your RFC "others do allow void functions in expressions, just as 
> PHP does, by making them implicitly return
> some unit type."
> You mentioned TypeScript -- unit type = null -- ActionScript -- unit type = 
> undefined -- and Swift -- unit type = empty
> tuple, ergo ().
> TypeScript [1] allows to return null, ActionScript does not allow to return 
> undefined, and Swift allows to return an
> empty tuple explicitly [2].
>
> I agree with others that is seems inconsistent to use the name void but allow 
> to use void functions in expression
> (return implicitly a unit type) and in the same time forbid to return the 
> unit type explicitly in such functions.
> IMO ActionScript should have allowed to return the unit type explicitly as 
> well and so should PHP.
> At first I did not like the idea of introducing void in PHP at all if it has 
> not the same behaviour as in C -- meaning
> it should be forbidden to use void functions in expressions -- but now I 
> think it better suits PHP if void stands for
> return nothing (hence null implicitly) or null explicitly. I think you should 
> change your RFC to allow returning
> explicitly null for two reasons:
>
> 1. Implicit and explicit behaviour should be consistent. If a function 
> returns null implicitly then it should be allowed
> to return null explicitly.
> 2. Not everyone might be aware of the implicit behaviour and some code 
> conventions might want to be explicit on this
> part and dictate that one needs to express the behaviour in code.
>
> To conclude, personally I want that the following are all equivalent:
> function foo() : void {}
> function foo() : void { return; }
> function foo() : void { return null; }
>
> To go a step further, I kind of like the idea that using the return value of 
> a void function results (at least) in an
> E_NOTICE. But maybe that is something for PHP 8.

I dislike this, because it punishes dynamic code (function composition).

For example:

$logUtility = partialLeft(function(string $a, string $b): void {
syslog(LOG_INFO, $a . ": " . $b);
});

$log = $log("Prefix");
$log("blah"); // writes "Prefix: blah" to the log

function partialLeft(callable $cb) {
return function($left) use ($cb) {
return function($right) use ($cb, $left) {
return $cb($left, $right);
};
};
}

Boom, notice.

Now, we could say that "that's the problem of the caller of
partialLeft", but the notice is raised inside of the closure inside of
partialLeft. Which would imply that it did something wrong. Something
that it couldn't possibly know about without booting a
reflectionfunction for it.

This would mean that generic higher order functions would need to be
duplicated, one for void functions and one for non-void functions. A
bit overkill...

That's just my $0.02

Anthony

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

Re: [PHP-DEV] Port random_bytes to PHP 5

[Anthony Ferrara]

Tom,

On Tue, Oct 13, 2015 at 10:17 AM, Tom Worster  wrote:
> On 10/12/15 10:53 PM, Larry Garfield wrote:
>>
>> On 10/12/2015 07:29 PM, Tom Worster wrote:
>>>
>>> Could we regard random_bytes() as a security patch rather than a new
>>> feature and therefore port it to PHP 5?
>>>
>>> Error handling would have to change but that should be feasible. Iirc,
>>> earlier commits of random_bytes() had PHP 5-like behavior on error.
>>>
>>> My motivation: it's easier to defend abandoning OpenSSL's RNG (e.g. in
>>> paragonie/random_compat) if we could say to Windows users stuck with
>>> nothing else: "Upgrade to the latest point release of PHP 5.x. It has a
>>> proper fix."
>>>
>>> Tom
>>
>>
>> Since there's no 5.7 release planned, you're talking about adding it in
>> a 5.6.x?
>
>
> Yes, maybe even 5.5?
>
>
>> What's wrong with the random_compat library as a solution for
>> 5.6 users?
>
> Good question. Vexing answer. I try to be brief.
>
> There are real situations that push random_compat into a corner with only
> unpleasant options, namely recommending the user install the unsavory mcrypt
> ext, which provides mcrypt_create_iv(), or resort to OpenSSL's RNG, which is
> just scary.
>
> There are recent discussion of this in a few places, I think you can find
> them all starting here https://github.com/paragonie/random_compat/issues/5
>
> So I thought another option would be to say "patch your PHP". One
> possibility to do that is what I proposed above.
>
> [I hesitate to mention it but, another is to make mcrypt_create_iv()
> independent of libmcrypt and present in standard builds of PHP. Maybe the
> latter is better because existing scripts that test
> function_exists('mcrypt_create_iv') become more secure.]
>

Overall, I don't think this should be ported back to 5.x

First off, it's pretty late in both 5.5 and 5.6 lifetimes (5.6 is
already up to .14).

Introducing a feature this late would basically make it useless to the
vast majority of users of those versions (since many don't upgrade, or
use distro-pinned versions). I don't like it, but that's the truth.

random_compat serves this need quite nicely, but as always there are
non-trivial tradeoffs at play.

As far as making mcrypt_create_iv more standard, why? That's what
random_bytes() was meant to do (and does). Just encourage people to
move forward with it and upgrade to 7...

Anthony

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

Re: [PHP-DEV] Scalar type hints and scalar type name aliases causeconfuson

[Anthony Ferrara]

All,

On Tue, Oct 13, 2015 at 9:56 AM, Rowan Collins  wrote:
> Andrea Faulds wrote on 13/10/2015 12:00:
>>
>> Hi Michael,
>>
>> Michael Wallner wrote:
>>>
>>> On 12/10/15 21:23, Andrea Faulds wrote:

 Even if we can't reserve the names, I hope we can do the two other
 suggestions in time for release.
>>>
>>>
>>> Additionally, we could say "instance of class ...".
>>>
>>
>> We could do that, though it's already 'instance of'. Not sure on this one.
>
>
>
> It's not necessarily a class you're requiring an instance of, it could (and
> according to some design disciplines "should") be an interface. I think the
> "did you mean..." is more useful if we don't make everything alias.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>


I think it's important to clean up these error messages and make it
easier to find the root problem.

With that said, I strongly believe that adding new reserved classes is
the wrong way to do that. Part of the problem is inconsistency around
what we call types in the first place. This leads to confusion around
what types people expect and how they expect them.

An example is the fact that types are different all over the place.
Cast tokens, the return of gettype(), documentation, etc.

Everything is inconsistent. And reserving extra types because of this
inconsistency does nothing to actually fix the problem.

Instead, my suggestion would be to double-down on clarifying that
"int"/"float"/"bool"/etc are the canonical correct versions, and
everything else is an alias. In future versions (likely 8, but
possibly earlier) we could deprecate the aliases, to keep things far
more consistent.

Reserving more classes now (both 7.0 and this late in the RC process)
is IMHO not a great idea. Either side sucks (whichever we do we're
wrong), but at least not reserving gives us a path towards cleaning it
up rather than making it worse.

I like Derick's suggestion (though removing "class"):

Fatal error: Uncaught TypeError: Return value of foo() must be an
instance of boolean, scalar boolean returned

The "instance" says it's an object.

The rest of it becomes a documentation problem. We're already mostly
consistent in the docs (all of the signatures use the correct tokens),
so it shouldn't be hard to finish that off...

My $0.02 at least.

Anthony

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

Re: [PHP-DEV] Remove name mangling? (when creating variables from external sources)

[Anthony Ferrara]

Hey,

On Tue, Oct 6, 2015 at 4:38 PM, Bishop Bettini  wrote:
> Hi!
>
> Currently dots and spaces are converted to underscores when pulling them in
> from HTML:
>
> 
> 
> 
> 
> 
> 
> 
>
> Ostensibly[1], names were mangled to support import_request_variables and
> register_globals.  But curiously other characters that would create an
> invalid variable aren't mangled:
>
>  
>
> There are already two bug requests out there asking to remove this behavior
> or expose the original name: #34882 and #42055
>
> Since 5.4.0 removed both import_request_variables and register_globals,
> does this mangling serve any purpose?  If not, can we remove it?
>
>
> [1] http://php.net/manual/en/language.variables.external.php
> [2] https://bugs.php.net/bug.php?id=34882
> [3] https://bugs.php.net/bug.php?id=42055

I'm all for this. Mangling has always seemed ...weird... Pulling it
out is awesome.

However, it also would be a pretty non-trivial BC break for people who
rely on the mangling. This would be likely something for 8?

Anthony

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

Re: [PHP-DEV] Arrow function expressions in PHP

[Anthony Ferrara]

Nikita and all,

On Thu, Oct 1, 2015 at 10:58 AM, Nikita Nefedov  wrote:
> On Thu, 01 Oct 2015 15:33:51 +0300, Rowan Collins 
> wrote:
>
>> That's not how Rasmus expressed it
>> [http://marc.info/?l=php-internals=144107616411299=2]:
>>
>>  > I made a very deliberate decision In the very first implementation of
>> PHP to avoid scope side-effects like this. Inside a function everything is
>> local unless explicitly declared not to be. This has carried through for the
>> past 20+ years in slightly different ways, but the basic rule has stayed
>> consistent even for closures.
>
>
> Ok, it proves that it's not evolutionary that scopes aren't chained. Taking
> my words back.
>
>
>> It is a tool for making them shorter, yes, but it is not the only way, and
>> it comes with a cost of changing established behaviour. Again, look at C++'s
>> lambda syntax - it is much shorter than PHP's, but requires a list of all
>> variables from the outer scope being captured.
>
>
> C++11 doesn't *require* the list of all variables, but it does require
> explicit "wildcard" ([=] for copy semantics, [&] for capturing by
> reference).
> But C++ is not the best place for picking up syntax choices, quite frankly
> it's one of the least readable languages in a way that it allows you to
> write very cryptic code easily (but still allows to write perfectly readable
> code as well).
> I'm not aware of reasons why ISOCPP decided that automatic capture should be
> disabled by default, maybe it was because it was hard to decide whether it
> should default to by-value or to by-reference semantics, or maybe [] tokens
> were needed because of parsing limitations.
>
>
>> You've picked on one syntax I explicitly labelled as "a straw man", and
>> one idea which was proposed by somebody else a few hours ago, and use those
>> to somehow dismiss the whole idea of a short syntax which lists captured
>> variables. I have come up with about a dozen different ideas in various
>> parts of this discussion, and could list dozens more. They would all have
>> their pros and cons, but I don't see how you can dismiss the whole concept,
>> UNLESS you consider the auto-capture to be an end in its own right, rather
>> than "just a way of making it shorter".
>
>
> I don't think there was a dozen of different ideas, I could only find those
> about `lambda(arg-list; use-list; expression)` and variations of it with
> different keywords and different return-type syntax.
> I do understand that this is quite subjective, but neither this syntax nor
> `fn(arg-list; use-list) expression` look obvious and easily readable to me.

The problem is that semicolons are non-obvious, especially in a
context where commas are used (and traditionally used).

Example, tell the difference quickly between

fn($a, $b; $c) => $a + $b + $c;

and

fn($a; $b, $c) => $a + $b + $c.

At a glance, they are identical. You have to actually look at each
item to realize that there's a difference. At least with use() there's
a syntactical separator there to draw your eye to the contextually
relevant information.

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

Re: [PHP-DEV] PHP 7.0.0RC4 is available

[Anthony Ferrara]

Congrats!!!

Thank you so much for what you are doing! Keep up the awesome work!

On Thu, Oct 1, 2015 at 9:02 AM,   wrote:
> Hi,
>
> The fourth release candidate for 7.0.0 was just released and can be
> downloaded from:
>
> https://downloads.php.net/~ab/
>
> The Windows binaries are available at
>
> http://windows.php.net/qa/
>
> This release contains fixes for 22 reported bugs and over 100 commits with
> various improvements.
>
> Please test it carefully, and report any bugs in the bug system.
> The next scheduled release is going to be tagged on October 13th and
> released on October 15th. It will be RC 5.
>
>
> Below is the verification information for the downloads:
>
> php-7.0.0RC4.tar.bz2
> SHA256 hash:
> 5475a6856b600a7a4f31a0276339725140d64da31a8a363e0cdb45ed233f27cd
> PGP signature:
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEcBAABAgAGBQJWCwezAAoJELyqMOqcDVdjxagH/2CO5m/n/obdXnEvo2vS1SQ3
> Ndo7ahNbcEuGyjsaT97SY60wOGKQgH28FIiF/onhLwNlGycApollGA0UzZlBj0dg
> W+vEUJFbiVLfn7Ro0PLtjJAQFrs7aLfsQea0sZCLLwpBon80BByYcDLDnDNRymHL
> 41fDECMUpCq6mlLABjGQv6D2jHlyvNsOcN1q5tonhduWbaNrJWRZrAYZStlndYub
> OracfXq3t2Df2Qf71XnltFUB8JB8oMZOt89DdkqENsnaGtfs98M7DTP33wGW8OIy
> l2wDqOLNyVbKrTNxQleY3NEZPYzzuaf1O+v7DIMA7+xSumv67TGBg+0KD1Wjm8M=
> =N579
> -END PGP SIGNATURE-
>
>
> php-7.0.0RC4.tar.gz
> SHA256 hash:
> bc9537f9bca7b945adae0fdc6e4f2eb592e5a01695b7a2c304d54b5894bf477d
> PGP signature:
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEcBAABAgAGBQJWCwe3AAoJELyqMOqcDVdjKVMH/2FGukuBkpy+SH6moKzZqR/J
> gv59x8rvOFCgu9AfxXTsJC4XWw9+aySAM27/7tgb6tI2ECHiaWU3MjCk8YK5o+bK
> bbz5sHErMTYiARjAtRnuzZ/fkB/VkCAZKNKt8nu3YqAsXrCu59keha1RNCX3gpWj
> qJ4wR+FSuuPq0bQ+P5pxB2j58lUYT91IgglvC+Nu8RZjRZfMaWB1ASnUsRyd3LcK
> 9k6UGWJ1i88i1/mEeZkzGerAz7Oje319T4U4vLQydSpKLvxuU9F31ORR2TfVD27P
> Gh08qb4V4gABbRAoY6Cy+a8yS0nkuZ+XuVNhv1ZryJBJPdXtaiUrHbpdfv0gyYU=
> =dkvk
> -END PGP SIGNATURE-
>
>
> php-7.0.0RC4.tar.xz
> SHA256 hash:
> d4cb3fd02f3f58ccc372da100757e900ddb9cfec118ba695382755a9f1c8215b
> PGP signature:
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEcBAABAgAGBQJWCwe6AAoJELyqMOqcDVdj7BIIAIgOvp5Siqos+egTLDhnOwUG
> qmo1/aYi7FMFHy0fze5Mt01EX1TnKxTlYohxk+qsG9tukywKeNwUj2axguF/QjrN
> qxofSRV2ue7JtQbjeH326k0mxbgz1uaxVtzUuOK5/BwH0zd2kqbVtbe4g5A6/oi2
> fT6c2UYYxvhT4Vsbj9R1vXDe+ElsdrYPg/MDtbAGzA+EajMka6xy6o62ZEev8DO5
> n4fRxQ+GtachREeLpAuMxjN8Gr4BmibbjheUWVKWhhujHkICq7B0iK1MocFzQPMe
> Gk3uP/bMgLxlwkNakiXqT8QVJdVjbWPeK8kYoMp3GzOE0hccK7Wc23e5C1ht2OQ=
> =aM22
> -END PGP SIGNATURE-
>
> Regards,
> Kalle Sommer Nielsen, Anatol Belski and Ferenc Kovacs
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

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

Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?

[Anthony Ferrara]

Thomas,

On Tue, Sep 29, 2015 at 11:22 AM, Thomas Hruska  wrote:
> On 9/29/2015 6:52 AM, Joe Watkins wrote:
>>
>> We shouldn't reserve words on a whim ...
>>
>> async/await doesn't solve any problems for multithreaded programming, at
>> all ... it solves problems for asynchronous programming, a different
>> concept ... let's not confuse the two ...
>
>
> Actually, it does.  Asynchronous and multithreaded programming are attempts
> at solving the exact same problem:  Simultaneously handling multiple data
> streams in whatever form that takes whether that be network, hard drive,
> random device XYZ, RAM, or even CPU.

Parallelism and concurrency are not the same thing. There are a ton of
resources on this, but I'll point to two specifically, Rob Pike (from
GoLang): https://www.youtube.com/watch?v=cN_DpYBzKso and Joe's own
blog: http://blog.krakjoe.ninja/2015/07/the-universe-is-not-aware.html

> Async/await is both the best of and THE solution to both worlds.

A whole lot of people would argue that. It's not that it's not a good
solution, but it's *A* solution. Each mechanism (event loops,
threading, channels, compiler-driven-concurrency, etc) has its own
pros and cons, and handle different situations better.

A simple example is that raw threads can scale across CPUs, but event
loops typically can't (since it's typically single threaded). That's
not to say it's impossible to write a cross-CPU event loop, but that
requires additional implementation/constraints.

There are such non-trivial tradeoffs to each, that there's no clear
"best" solution to any of it. Async/await is one way. Golang's
channels are another subtly different yet very good way as well.
Another even better way may be to take an approach which is to leave
it to the compiler to figure out what can be made async (though that
may not be strictly possible with PHP in most cases).

Claiming that one technique is the victor, without explicitly stating
the constraints that are required, is not a great idea.

Anthony

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

Re: [PHP-DEV] Re: [RFC] [VOTE] Short Closures

[Anthony Ferrara]

Stas,

On Thu, Sep 24, 2015 at 2:21 PM, Stanislav Malyshev  wrote:
> Hi!
>
>> How does one then address that this RFC only covers a subset of
>> Hacklang functionality when having the same operator?
>
> Why one should address it? PHP is a different language, and we are under
> no obligation to completely match functionality of any other language.

Correct. We are under no obligation. But, it would be us playing
friendly neighbor and responsible community citizen if we didn't
re-use syntax in a different way. Remember, Hack isn't some arbitrary
different language, it's one that exists in the PHP ecosystem. We are
under no obligation to play nicely with them, but wouldn't it be nice
if we did anyway?

And part of that playing nice would be not re-using syntax in
different ways (that goes in both directions). Since that only will
make everyone's life more difficult.

Anthony

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

Re: [PHP-DEV] [RFC] [VOTE] Short Closures

[Anthony Ferrara]

Dmitry,

On Tue, Sep 22, 2015 at 2:05 PM, Dmitry Stogov  wrote:
> On Tue, Sep 22, 2015 at 7:01 PM, Bob Weinand  wrote:
>
>>
>> > Am 22.09.2015 um 17:36 schrieb Dmitry Stogov :
>> >
>> > On Tue, Sep 22, 2015 at 4:54 PM, Joe Watkins 
>> wrote:
>> >
>> >> I'd really like to understand what you're trying to say there Dmitry,
>> but
>> >> I don't get it.
>> >>
>> >> What is your example function trying to show ?
>> >>
>> >> As it mentions in the RFC, vars in short closure are by-value, so I
>> can't
>> >> see what side effects you might be thinking of ?
>> >>
>> >
>> > It's clear to me that foo() will return NULL, but how many warnings about
>> > unused variable $y will we get?
>> >
>> > Thanks. Dmitry.
>> >
>> >
>> >>
>> >> Cheers
>> >> Joe
>> >>
>> >> On Tue, Sep 22, 2015 at 9:25 AM, Dmitry Stogov  wrote:
>> >>
>> >>> I'm against the magic - "automatically use () all of the (compiled)
>> >>> variables".
>> >>> I'm also against compound short closures with curly brackets.
>> >>> in my opinion they opens too many ambiguous questions.
>> >>>
>> >>> function foo() {
>> >>>  (($x) ~> {$y = 3; return $y + $x;})(5);
>> >>>  return $y;
>> >>> }
>> >>>
>> >>> also think about nested closures and use of variables from not direct
>> >>> enclosure.
>> >>>
>> >>> I'm not sure if we need all "functional programming" features in PHP,
>> but
>> >>> if we introduce them, lets do it consistently with the existing
>> language.
>> >>> I think, this proposal can't be approved without support for type
>> hinting.
>> >>>
>> >>> Thanks. Dmitry.
>> >>>
>> >>> On Tue, Sep 22, 2015 at 4:59 AM, Bob Weinand 
>> wrote:
>> >>>
>>  Hey,
>> 
>>  Thanks for all your feedback in the discussion thread!
>> 
>>  So, before I start the vote, just two quick notes:
>>  I've added two notes about the statement syntax and the single
>> variable
>>  use.
>>  Though a few people complained, I'm not switching to the ==> operator,
>> >>> as
>>  I noticed many people expected typehints to work (they don't due to
>> >>> parser
>>  limitations) when they compared to Hack's short Closures. It also
>> >>> allows us
>>  to differ syntax-wise [e.g. for typehints] from Hack without causing
>> any
>>  confusion later. Which should be the smartest choice: Avoid conflicts.
>> >>> (If
>>  anyone strongly feels against that, he may vote no, but I would like
>> to
>> >>> not
>>  bikeshed that in this Vote thread, but leave it free for eventual
>> actual
>>  issues.)
>> 
>>  Now, the link to the RFC about Short Closures:
>>  https://wiki.php.net/rfc/short_closures
>>  or straight ahead to the vote:
>>  https://wiki.php.net/rfc/short_closures#vote
>> 
>>  Thanks,
>>  Bob
>>
>>
>> Notice: Undefined variable: y in php shell code on line 3
>>
>> It just yields exactly one notice about the inexistent $y (as it obviously
>> does not leak through the scope): by-value binding.
>>
>> I'm not sure what your issue here is?
>>
>
> The current PHP version emits two warning on similar constructs, and this
> is explainable because we explicitly "use" $y.
>
> $ sapi/cli/php -r 'function foo(){(function($x) use ($y){$y=3; return
> $y+$x;})(5);return $y;} var_dump(foo());'
> PHP Notice:  Undefined variable: y in Command line code on line 1
>
> PHP Notice:  Undefined variable: y in Command line code on line 1
>
> NULL
>

There's an important distinction here. The explicit `use($y)` triggers
a notice because you said to use an undefined variable.

function foo() {
  (($x) ~> {$y = 3; return $y + $x;})(5);
  return $y;
}

In this case, there's no practical binding of `$y` at all. The `$y` in
the scope of the closure is never actually read from before it is
assigned to. Meaning the variable doesn't need to exist prior to that
assignment, meaning that it doesn't have to be bound (used), and as
such shouldn't throw a notice.

This becomes a ton easier if we ever move to an explicit CFG+SSA
compile step. Then, we can see which variables dominate the closure to
see what needs to be bound vs what doesn't. In this example, converted
to SSA, you'd see:

function foo() {
  $y1 = 12;
  (($x1) ~> {$y2 = 3; return $y2 + $x1;})(5);
  return $y1;
}

Hence you can see that `$y2` is truly an independent variable, and
hence `$y1` never needs to be bound (and hence no notice).

So your case of explicitly using `$y` isn't actually what's happening
with the closure (at least with respect to userland behavior). Hence
why the lack of notice exists.

My $0.02 at least,

Anthony

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

Re: [PHP-DEV] [RFC] [VOTE] Short Closures

[Anthony Ferrara]

Dmitry,

On Tue, Sep 22, 2015 at 3:19 PM, Dmitry Stogov <dmi...@zend.com> wrote:
>
>
> On Tue, Sep 22, 2015 at 9:20 PM, Anthony Ferrara <ircmax...@gmail.com>
> wrote:
>>
>> Dmitry,
>>
>> On Tue, Sep 22, 2015 at 2:05 PM, Dmitry Stogov <dmi...@zend.com> wrote:
>> > On Tue, Sep 22, 2015 at 7:01 PM, Bob Weinand <bobw...@hotmail.com>
>> > wrote:
>> >
>> >>
>> >> > Am 22.09.2015 um 17:36 schrieb Dmitry Stogov <dmi...@zend.com>:
>> >> >
>> >> > On Tue, Sep 22, 2015 at 4:54 PM, Joe Watkins <pthre...@pthreads.org>
>> >> wrote:
>> >> >
>> >> >> I'd really like to understand what you're trying to say there
>> >> >> Dmitry,
>> >> but
>> >> >> I don't get it.
>> >> >>
>> >> >> What is your example function trying to show ?
>> >> >>
>> >> >> As it mentions in the RFC, vars in short closure are by-value, so I
>> >> can't
>> >> >> see what side effects you might be thinking of ?
>> >> >>
>> >> >
>> >> > It's clear to me that foo() will return NULL, but how many warnings
>> >> > about
>> >> > unused variable $y will we get?
>> >> >
>> >> > Thanks. Dmitry.
>> >> >
>> >> >
>> >> >>
>> >> >> Cheers
>> >> >> Joe
>> >> >>
>> >> >> On Tue, Sep 22, 2015 at 9:25 AM, Dmitry Stogov <dmi...@zend.com>
>> >> >> wrote:
>> >> >>
>> >> >>> I'm against the magic - "automatically use () all of the (compiled)
>> >> >>> variables".
>> >> >>> I'm also against compound short closures with curly brackets.
>> >> >>> in my opinion they opens too many ambiguous questions.
>> >> >>>
>> >> >>> function foo() {
>> >> >>>  (($x) ~> {$y = 3; return $y + $x;})(5);
>> >> >>>  return $y;
>> >> >>> }
>> >> >>>
>> >> >>> also think about nested closures and use of variables from not
>> >> >>> direct
>> >> >>> enclosure.
>> >> >>>
>> >> >>> I'm not sure if we need all "functional programming" features in
>> >> >>> PHP,
>> >> but
>> >> >>> if we introduce them, lets do it consistently with the existing
>> >> language.
>> >> >>> I think, this proposal can't be approved without support for type
>> >> hinting.
>> >> >>>
>> >> >>> Thanks. Dmitry.
>> >> >>>
>> >> >>> On Tue, Sep 22, 2015 at 4:59 AM, Bob Weinand <bobw...@hotmail.com>
>> >> wrote:
>> >> >>>
>> >> >>>> Hey,
>> >> >>>>
>> >> >>>> Thanks for all your feedback in the discussion thread!
>> >> >>>>
>> >> >>>> So, before I start the vote, just two quick notes:
>> >> >>>> I've added two notes about the statement syntax and the single
>> >> variable
>> >> >>>> use.
>> >> >>>> Though a few people complained, I'm not switching to the ==>
>> >> >>>> operator,
>> >> >>> as
>> >> >>>> I noticed many people expected typehints to work (they don't due
>> >> >>>> to
>> >> >>> parser
>> >> >>>> limitations) when they compared to Hack's short Closures. It also
>> >> >>> allows us
>> >> >>>> to differ syntax-wise [e.g. for typehints] from Hack without
>> >> >>>> causing
>> >> any
>> >> >>>> confusion later. Which should be the smartest choice: Avoid
>> >> >>>> conflicts.
>> >> >>> (If
>> >> >>>> anyone strongly feels against that, he may vote no, but I would
>> >> >>>> like
>> >> to
>> >> >>> not
>> >> >>>> bikeshed that in this Vote thread, but leave it free for eventual
>> >> actual
>> >> >>>> issues.)
>> >> >>&

Re: [PHP-DEV] Let's discuss enums!

[Anthony Ferrara]

Levi et al,

On Fri, Sep 18, 2015 at 10:11 AM, Levi Morrison  wrote:
> On Thu, Sep 17, 2015 at 5:52 PM, John Bafford  wrote:
>> On Sep 17, 2015, at 19:16, Bob Weinand  wrote:
>>>
 Am 18.09.2015 um 01:06 schrieb Rowan Collins :

 This has come up in passing a few times recently, but I'm not sure there's 
 ever been a dedicated discussion of it: would it be useful for PHP to have 
 a built-in Enumeration type, and if so, how should it look?
>>>
>>> I like enums in general, but I'd like to note that there's already a RFC in 
>>> draft by Levi:
>>>
>>> https://wiki.php.net/rfc/enum 
>>>
>>> As far as I know, the RFC is already fairly final and just lacks an 
>>> implementation.
>>>
>>> So, I'd consider bikeshedding an actual RFC first.
>>
>>
>> If we’re bikeshedding, one feature I would really like to see, with 
>> typehinting, is warnings if all cases of an enum aren’t handled in a switch. 
>> So, for example, given our example Weekdays enum, if I wrote this code:
>>
>> switch(Weekday $someWeekday) {
>> case Weekday::MONDAY: break;
>> case Weekday::TUESDAY: break;
>> }
>>
>> By providing the typehint, I’m indicating that I want to get a warning/error 
>> that the switch does not cover all enum values. This would be very handy if 
>> an enum value is added after initial development and someone misses a switch 
>> statement in cleanup.
>>
>> The typehint would also allow generating a warning if someone did something 
>> like
>>
>> switch(Weekday $someWeekday) {
>> //case … all the weekdays: break;
>> case ‘I am not a Weekday’: echo ‘Generate a fatal error here because 
>> string is not a Weekday.’;
>> }
>
> I've looked into this but not in the same syntax you've provided. I
> was exploring a `match` construct that has different semantics:
>
> match ($foo) {
> case Weekday::Monday: {
> echo "Monday";
> } // it is not possible to fall-through with match/case
>
> case Weekday::Tuesday:  echo Monday; // single expression
> doesn't need braces
> } // if it hits the end without a match a runtime error will be emitted
>
> I think this fits into the dynamic behavior of PHP a little better
> than forcing a case for each enum value at compile-time, even if it
> was possible (I suspect it is not).

This is basically pattern matching. And while I'd LOVE to see support
for it in PHP, I think it's a bit off-topic here. Perhaps a new thread
could be opened for it (or ideally a RFC)...?

As far as enums, I wonder if they would be necessary if we supported
algebraic types, since you could define an "enum" as a virtual type:

const MONDAY = 0;
const TUESDAY = 1;
const WEDNESDAY = 2;
const THURSDAY = 3;
const FRIDAY = 4;
use MONDAY | TUESDAY | WEDNESDAY | THURSDAY | FRIDAY as WEEKDAY;

function foo(WEEKDAY $day) {
// must be an integer 0-4, or castable to 0-4 unless strict_types is on.
}

Just a thought...

Anthony

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

Re: [PHP-DEV] Make strict mode more strict?

[Anthony Ferrara]

Yasuo,

On Wed, Sep 16, 2015 at 6:10 PM, Yasuo Ohgaki  wrote:
> Hi all,
>
> PHP 7 has strict_types mode for function parameters/return values and
> these are binded to certain type strictly.
> https://wiki.php.net/rfc/scalar_type_hints_v5
>
> Why not make strict_types mode more strict?
> The idea is as follows:
>
>  declare(strict_types=1);
>
> function foo(int &$i) {
>   $i = "string"; // Raise error
>   $i = function_returns_string(); // Raise error
>   $i = 1234.5678; // Raise error
>   $i = function_returns_float(); // Raise error
>
>   $n = 123;
>// do something
>$n = array(); // Raise error
> }
> ?>
>
> Assigning different type to already initialized variable is a bug most
> likely. There may be cases that variable should have several types,
> e.g. return INT for success and FALSE for failure, but programmers can
> use different variable or return value directly or make BOOL/NULL
> exception.
>
> This is useful with reference especially. For example,
>
>  declare(strict_types=1);
>
> function foo(int &$i) {
> $i = 'string';
> }
>
> $i = 0;
> foo($i);
> var_dump($i);
> ?>
>
> outputs
>
> string(6) "string"
>
>
>
> Just an idea. Any comments?
>

First, as mentioned by others, this really doesn't have overly much to
do with strict_types. It's introducing a new concept (which could
potentially be a new declare statement).

Second, i think the biggest limitation here is technological. If you
can find a way internally to type variables properly while keeping
copy-on-write semantics, then we can start that conversation on
whether we really want to do that or not. But so far, everyone I've
seen try to do something like that (namely for typed properties) has
wound up causing all sorts of weird edge-cases around references or
copy-on-write. Which is one reason we haven't seen a full proposal yet
for it.

So if you can come up with a patch that works, let's definitely talk
about it. But as Stas said, it's really not just making types more
strict, but it's fully blown variable typing. Which we can talk about,
but let's talk about explicitly (and preferably with an implementation
approach).

Thanks!!!

Anthony

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

Re: [PHP-DEV] taint

[Anthony Ferrara]

All,

On Tue, Sep 15, 2015 at 11:15 AM, Arvids Godjuks
 wrote:
> I fully support your effort to get this into the PHP to be part of core
> extensions, or at least one of those that keep up with the language
> releases.
> This is a very good tool to have, and you can actually run it in production
> to catch things that may slipped the stating (things happen). And it's
> invaluable during during testing.

I'm against any form of tainting for a few reasons.

First, it's only really useful as a first-order heuristic. A failure
does not indicate a security vulnerability, and a non-failure does not
indicate the absence of one. An example of a false-positive would be
if (preg_match('(^[a-z0-9]+$)', $input)) echo $input;. Taint-based
systems would flag that as a possible XSS, where it's clearly not in
any context. An example of a false-negative would be the following:

>Bar. If the
input is "foo onclick=dosomethingbad();", an XSS is still executed.

Another example of a false negative would be:

$query = "SELECT * FROM foo WHERE bar = " .
mysqli_real_escape_string($c, $input) . ";";

A false positive is potentially OK. A false negative is not.

Second, it will encourage the improper pattern of "sanitize" functions
to de-taint input. These are functions which call
`mysqli_real_escape_string(htmlspecialchars(whatever(etc($input`.
No matter what the context the variables are used in. This doesn't
improve security (and in many cases can demonstrably harm it). It just
encourages people to work around it. And that ignores that there's an
`untaint()` function that they can call on any variable to "silence
the errors".

Third, it ignores context. This is related to the first two, but I
think is a separate concern. An example from the taint RFC
(https://wiki.php.net/rfc/taint) is the shell-execution. If the
variable is used in the context of command, one escape function is
needed. If it's used as an argument, another is needed. Detecting
which is not something that's trivial for a language-level taint
function. And calling the wrong function defeats the purpose. So if we
can't detect the context, we can't reliably say whether it's safe or
not.

In the hands of an experienced engineer/security researcher, taint
systems can be a really handy tool to help find possible issues. In
the hands of a junior engineer, it can actually make things worse
because it encourages them to just "silence the errors".

Considering that it's not a reliable tool, and is only a heuristic, I
would suggest that this be implemented as an extension, and not in the
core of a programming language.

With that said, if there are engine hooks necessary to implement this
feature better as an extension, I'm all for adding those hooks. I'm
just against adding something to the language that won't actually be
able to accomplish what it promises.

Escaping is always context-sensitive, in every case. Tainting as has
been proposed in the past doesn't (and literally can't in the general
case) know the context. Therefore it can't reliably know the correct
way to escape.

Consider the case of addslashes() and magic_quotes_gpc. The reason
that they are insecure is that they don't know the context that the
variable is used in. This leads to character set issues, as well as
cases where backslashes enter contexts they don't escape (like HTML
output). We learned years ago that context-insensitive escaping
doesn't work and is literally bad. Let's not make the same mistakes
again (even if it's for the correct reasons this time).

Anthony

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

Re: [PHP-DEV] Re: [RFC] [Discussion] Short Closures

[Anthony Ferrara]

Rowan

On Mon, Sep 7, 2015 at 10:14 PM, Rowan Collins  wrote:
> Andrea Faulds wrote on 06/09/2015 22:54:
>>
>> Also, it would be nice if PHP and Hack don't diverge when implementing the
>> same features, unless there's a particularly good reason... it's not very
>> kind to people who use both languages.
>
>
> While I agree with the sentiment of them not diverging, the problem is that
> it gives the authors of Hack a disproportionate influence on PHP. At the
> extreme, if someone wanted to push through their version of a feature, they
> could get it released in Hack first, then raise an RFC citing Hack
> compatibility as the reason for the design decisions. (Important: I am not
> accusing anyone of doing this.)t, IMHO.

Being completely fair, doesn't this actually make HackLang a great
test-bed for PHP features? If they implement something, and people
hate it/it sucks, boom. But if people love it, it's a no brainer for
us to "steal".

I don't think we should blindly accept anything because it's in hack,
but the fact that it's there means we also shouldn't diverge "just
because". If it makes sense to copy it, why not?

The one thing I think we absolutely MUST avoid is changing behaviour
slightly but keeping same syntax.

For example, if we used ==> for short closures but used a different
semantic. That would be *really* bad. That leaves us with either
taking their semantics whole sale for the feature, or creating our own
syntax. That's what Bob has proposed here.

Overall, I think we should steal outright what makes sense (I use
steal weakly here, it's collaborative). We should take inspiration
where it makes sense, and we should forge our own road where it makes
sense.

I have not a single ounce of reservation about "giving authors of Hack
a disproportionate influence on PHP". They are not being given a blank
check, no more than any other contributor is. But we also shouldn't be
stupid and ignore what they are doing because of pride (or whatever
else).

My $0.02

Anthony

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

[PHP-DEV] Re: [RFC] [Vote] Random Functions Throwing Exceptions in PHP 7.0.0

[Anthony Ferrara]

Voting is now closed. The proposal is accepted 28:2.

I will merge PR #1379 to master tomorrow (to give time for a final code-review).

https://github.com/php/php-src/pull/1397

Thanks all!

Anthony

On Sun, Aug 30, 2015 at 6:54 PM, Anthony Ferrara <ircmax...@gmail.com> wrote:
> All,
>
> I have opened voting for the Random Functions Throwing Exceptions RFC
> as the required week of discussion time has passed with minimal
> discussion.
>
> https://wiki.php.net/rfc/random-function-exceptions
>
> Voting will close at 07:00 UTC on Sunday, September 6 (1 week from today).
>
> Anthony

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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

[Anthony Ferrara]

Pavel

On Tue, Sep 1, 2015 at 4:32 AM, Pavel Kouřil  wrote:
> On Mon, Aug 31, 2015 at 9:29 PM, Bob Weinand  wrote:
>> I had this RFC in draft since some time, but delayed it due to all the 
>> ongoing PHP 7 discussions. Also we have no master branch to merge features 
>> in until 5.4 EOL. Thus I'm reviving this now.
>>
>> Time for the first RFC targeting PHP 7.1 (assuming PHP 8 isn't going to be 
>> the next version ;-)):
>>
>> The short Closures RFC:
>> https://wiki.php.net/rfc/short_closures
>>
>> Hoping for constructive feedback,
>> Bob
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
> Hi,
>
> as a purely userland developer, I would definitely appreciate the
> shorthand function for anonymous functions; having tons of stuff like
> "function ($x) { return $x * 2; }"  makes the code less readable in
> the end.
>
> I'm not sure about the "auto using" of all variables though; wouldnt
> it be possible to statically check for the used variables and only
> import what's needed, for performance reasons?

That's precisely what's happening. Not all variables are bound, only
those that are used. Somehow somewhere in this thread the confusion
was implied that the entire scope is copied.

> Also, how hard would it be to add type hints (only for parameters)?
> Sometimes they are needed to make the IDE know the variable type
> because it can't be guessed automatically. I know about your note in
> RFC,this is just a question to other internal members.Return type can
> be infered by IDEs from the simple expresion quite easily.
>
> PS: would "() ~> foo()" work? I think it should, but I couldn't find a
> mention about it in RFC. :)

Typing on closures is outside the scope of this RFC.

With that said, I'd love to hear and see examples of this. It's
something I definitely want to do, just haven't come up with a good
enough way to do it...

Anthony

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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

[Anthony Ferrara]

Stas,

On Mon, Aug 31, 2015 at 11:46 PM, Stanislav Malyshev
 wrote:
> Hi!
>
>> Here it is very obvious that we want to import a variable. Especially, I 
>> wonder how
>> $array = array_map(function ($x) use ($y) { return $x + $y; }, $array);
>> is making such simple applications more readable? And especially, what value 
>> does it add here?
>
> It is making it more readable by explicitly specifying that we're using
> function, that this function imports $y from parent scope and returns $x
> + $y. Of course, a seasoned programmer that has years of experience in
> functional languages would recognize this pattern, but that's not
> exactly the main target audience of PHP.

I think that's quite a bit hyperbolic of an argument.

Most programming languages today have a "short form" closure or lambda syntax

HackLang: ($x) ==> $x + 1;
C++: [](int x) -> int { return x + 1; }
Java: (int x) -> x + 1;
Python: lambda x: x+1
Ruby: lambda |x| { x + 1 }
Rust: |x| x + 1
JavaScript (ES6): x => x + 1
C#: x => x + 1
Objective C: ^(int x) { return x + 1; }

Note that not a single one of those is a "functional" language. That's
every language in the top 10 index except PERL, PHP and VB.NET (though
VB has a similar syntax: function (x as Integer) x + 1),

I agree that at first it will feel a little bit weird, especially
given that PHP in general lacks syntactic sugar (we still don't have a
short-hand to initialize stdclass objects). We introduced [] back in
5.4, and largely it has made readability FAR better (despite some
people saying it wouldn't at the time).

> And I do not think the argument "you don't have to use it" is a good one
> for adding language syntax constructs. If it's in the language, you'd
> have to deal with it, and you'd have to teach other people to deal with
> it. It's not some function sitting in the extension that may not even be
> loaded - it's part of language syntax. So if it would encourage
> write-only code, you'd have to deal with it even if you don't personally
> create write-only code.

I agree 100%. "you don't have to use it" sucks as an argument. However
I don't think that's what Bob meant. He was trying to convey that the
tool isn't always appropriate in all situations. You can craft code
that makes this new syntax look unreadable. But you can craft code
that makes this look far more readable.

Example:

function partial(callable $cb) {
return function($left) use ($cb) {
return function($right) use ($cb, $left) {
return $cb($left, $right);
};
};
}

vs:

function partial(callable $cb) {
return $left ~> $right ~> $cb($left, $right);
}

It may look weird at first, but consider that's because you're not
used to the syntax. To me, the top is far harder to follow because of
the shear number of tokens to follow, not to mention that I need to
pay attention to the use-blocks which may or may not be importing
certain variables. The bottom reads exactly how I would expect it to.

Both are completely explicit in what they do and how they behave.

That's my opinion anyway...

Anthony

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

[PHP-DEV] [RFC] [Vote] Random Functions Throwing Exceptions in PHP 7.0.0

[Anthony Ferrara]

Try number 2, when I sent this yesterday it didn't seem to come through.
On Aug 30, 2015 6:54 PM, Anthony Ferrara ircmax...@gmail.com wrote:

 All,

 I have opened voting for the Random Functions Throwing Exceptions RFC
 as the required week of discussion time has passed with minimal
 discussion.

 https://wiki.php.net/rfc/random-function-exceptions

 Voting will close at 07:00 UTC on Sunday, September 6 (1 week from today).

 Anthony

[PHP-DEV] [RFC] [Vote] Random Functions Throwing Exceptions in PHP 7.0.0

[Anthony Ferrara]

All,

I have opened voting for the Random Functions Throwing Exceptions RFC
as the required week of discussion time has passed with minimal
discussion.

https://wiki.php.net/rfc/random-function-exceptions

Voting will close at 07:00 UTC on Sunday, September 6 (1 week from today).

Anthony

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

[PHP-DEV] [RFC] [Discuss] Random Functions Throwing Exceptions in PHP 7.0.0

[Anthony Ferrara]

All,

I am putting a simple RFC up for discussion to make random_* throw
exceptions on failure in order to ensure we fail-closed.

https://wiki.php.net/rfc/random-function-exceptions

Considering this topic has already been discussed, I intend to open
voting on this as soon as allowable. Given the voting policy specifies
2 weeks for language changes and 1 week for another, this is assumed
to require 1 week of discussion.

With that in mind, I intend to put this RFC up to vote on August 29/30th.

Thanks!

Anthony

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

Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7

[Anthony Ferrara]

Anatol,

On Sat, Aug 22, 2015 at 10:34 AM, Anatol Belski anatol@belski.net wrote:
 Hi Anthony,

 -Original Message-
 From: Anthony Ferrara [mailto:ircmax...@gmail.com]
 Sent: Saturday, August 22, 2015 4:44 AM
 To: Pierre Joye pierre@gmail.com
 Cc: Anatol Belski anatol@belski.net; Scott Arciszewski
 sc...@paragonie.com; Niklas Keller m...@kelunik.com; Trevor Suarez
 ric...@gmail.com; PHP internals internals@lists.php.net
 Subject: Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7

 Pierre

 On Aug 21, 2015 22:33, Pierre Joye pierre@gmail.com wrote:
 
  On Sat, Aug 22, 2015 at 9:16 AM, Anthony Ferrara ircmax...@gmail.com
 wrote:
 
   If that's what it will take I will happily draft one tomorrow morning.
 But
   if the RMs are against it, I will respect that as well. Hence the
 dilemma.
 
  For what I understand the RMs are not against what it is proposed but
  its incompleteness and the fact that it affects the timeline for php
  7.
 
  The sooner will benefit from a RFC, making this whole discussion a lot
  clearer. The latter is a requirement to change, even slightly,
  anything about what we decided for php 7. The RMs role is to ensure we
  respect what we decided by RFC, hence the oppositions.

 By convention, it is also to decide which rfcs are applicable for a specific 
 release.
 I would like to respect that. If they say no, I won't waste time and energy 
 on the
 rfc process as it will be pointless as it won't affect 7.0. If they say yes, 
 then we
 can make it quick and as painless as possible and settle it once and for all.

 It bothers me though that it has to come down to this. But that's another
 discussion for another day.

 Thanks for your constructive responses and deferential conduct.

 Looking retrospectively t the RFC votes closing days noted in the wiki

 - engine exceptions on March 8th
 - CSPRNG on March 28th
 - Throwable on June 17th

 the engine exceptions and CSPRNG lay quite near in time, so it is obvious 
 CSPRNG implementation couldn't have been changed short before or after the 
 other one as they cross each other so close in time. A notable fact also is 
 that quite a new stuff in Throwable was taken already after release circle 
 start and the point of no accept for the new RFCs. In any case, by the times 
 so much of new functionality was clearly overmuch to digest. And it is still 
 even more of discovery for people not having PHP7 experiences.

 For what it matters, a suggestion about a need on a strategy with this matter 
 sounded in the early days of this discussion. Unfortunately it was not taken 
 seriously, which is sad as well. The exact goal of calling for RFC already at 
 that time was to bring all the bike shedding onto a productive path and to 
 avoid a situation like it is now. Actually this argument is nothing else than 
 bike shedding on the times and mindsets, so were not worth to mention. But 
 having not the 1.5 month time lost, we probably wouldn't stand where we stand 
 now.

 From what all the bike shedding crystalized, there are at least three main 
 directions to see, when it comes to throw in functions. Please correct me 
 when I'm wrong

 - security aspect (this discussion)
 - conversion of fatal errors (touched partially in a PR by Aaron)
 - ZPP handling (mentioned by Nikita)

 These look like they can be handled separately, what they have in common is

 - definition of Error and Exception use case
 - further development of the exception hierarchy

 Please don't catch me on the above, it is only what could be marked by my 
 mind from the discussions.

 From these, either there can be an RFC with a proper solution of one or all 
 the topics spliced with the possible delay of the PHP7 final awareness, or 
 there can be an RFC to include a partial solution being pushed so far and 
 possible inconsistency consequences, or CSPRNG functionality can be deferred 
 until a complete solution, or CSPRNG can be reimplemented as class where 
 exceptions belong to the natural flow, or a good sustainable solution can be 
 offered in 7.1. Any other ideas. From the time line - there are five release 
 slots until final yet. Were it an RFC which is accepted, the change would 
 land in RC3 most likely, that would mean there were yet three release slots 
 till final. Under the condition that the current timeline is held.

 From the last stand point discussed with the other RMs, as they seem not to 
 be reachable for a direct discussion most of today - such a change affects 
 long term features and language paradigm, which is the matter of the 
 community competence. There's the 7.0 timeline which is a voted thing, there 
 is a release process document which defines that the votes take place on RFCs 
 directly and not on the mailing lists. The RMs belief is that the suggested 
 change is the exact kind of needing a collective decision. Due to the 
 concerns explained earlier, the timeline RFC and other items seem to be in 
 clash

Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7

[Anthony Ferrara]

Pierre

On Aug 21, 2015 22:33, Pierre Joye pierre@gmail.com wrote:

 On Sat, Aug 22, 2015 at 9:16 AM, Anthony Ferrara ircmax...@gmail.com
wrote:

  If that's what it will take I will happily draft one tomorrow morning.
But
  if the RMs are against it, I will respect that as well. Hence the
dilemma.

 For what I understand the RMs are not against what it is proposed but
 its incompleteness and the fact that it affects the timeline for php
 7.

 The sooner will benefit from a RFC, making this whole discussion a lot
 clearer. The latter is a requirement to change, even slightly,
 anything about what we decided for php 7. The RMs role is to ensure we
 respect what we decided by RFC, hence the oppositions.

By convention, it is also to decide which rfcs are applicable for a
specific release. I would like to respect that. If they say no, I won't
waste time and energy on the rfc process as it will be pointless as it
won't affect 7.0. If they say yes, then we can make it quick and as
painless as possible and settle it once and for all.

It bothers me though that it has to come down to this. But that's another
discussion for another day.

Anthony

RE: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7

[Anthony Ferrara]

Anatol,

On Aug 21, 2015 8:10 PM, Anatol Belski anatol@belski.net wrote:

 Hi,

  -Original Message-
  From: Anthony Ferrara [mailto:ircmax...@gmail.com]
  Sent: Friday, August 21, 2015 3:37 PM
  To: Scott Arciszewski sc...@paragonie.com
  Cc: Pierre Joye pierre@gmail.com; Trevor Suarez ric...@gmail.com
;
  Niklas Keller m...@kelunik.com; PHP Internals internals@lists.php.net
  Subject: Re: [PHP-DEV] Recap - Core functions throwing exceptions in
PHP7
 
  On Fri, Aug 21, 2015 at 6:14 AM, Scott Arciszewski sc...@paragonie.com
  wrote:
   On Fri, Aug 21, 2015 at 3:52 AM, Pierre Joye pierre@gmail.com
wrote:
   On Fri, Aug 21, 2015 at 9:38 AM, Scott Arciszewski 
sc...@paragonie.com
  wrote:
   On Wed, Aug 19, 2015 at 11:36 AM, Trevor Suarez ric...@gmail.com
  wrote:
   Ah, I didn't realize this thread existed. I had just commented on
   the old one, but the point still stands:
  
   PHP 7.0 RC1 was just tagged.
   Shouldn't this be a relatively high priority to fix/decide so we
   don't end up with behavior that can't be fixed until PHP 8.0?
  
   On Mon, Aug 10, 2015 at 6:54 PM Niklas Keller m...@kelunik.com
wrote:
  
   
Okay, great, we have people on both sides on this discussion. I
hope nobody minds if I sit this part out.
   
What specifics need to be discussed? Should somebody set up a
poll? (I don't know how to do that.)
  
  
   You can find information on how to setup a poll in step 6 here:
   https://wiki.php.net/rfc/howto
  
   Regards, Niklas
  
   I agree that this should be a relatively high priority. I'm not sure
   what the next steps would be. (Aside: I still have a PR I need to
   write that I've been holding off on until the fate of PHP 7's CSPRNG
   feature is determined.)
  
   Can we reach some sort of consensus on throw new Exception vs throw
  new Error?
  
   I think the best would be a RFC, not only for the decision itself but
   also to have a clear view about what will be changed or affected.
  
   Cheers,
   --
   Pierre
  
   @pierrejoye | http://www.libgd.org
  
   Fine, let's do this:
  
   1. Violate the feature freeze for this exceptional decision.
   2. One of the folks in the camp that WANTS an RFC and a drawn out
   formal decision-making process opens it with a poll.
   3. Give me voting karma.
  
   Let's NOT make the CSPRNG feature fail open. That is an absolutely
   terrible idea.
 
  My proposal/stance:
 
  Let's make random_* throw an Exception if it cannot connect to a random
  source. And let's have it throw an TypeError if ZPP fails, or Error if
min = max.
 
  The first two are consistent with existing exceptions.
 
  The third (Error if minmax) is where the contention lies. I'm
suggesting Error as
  it's consistent with parameter errors in the sense that the type may be
correct,
  but the value isn't (hence it's the same kind of error as a parameter
error, just a
  different sub-classification.
 
  MHO is this is too important of a distinction to simply gloss over.
  Having it return false (or null) will be a problem, as nobody will
perform the error
  checks. And returning $x where `$x == 0` in a security context could be
incredibly
  bad. As such, I think the security implications here outweigh nearly
all of the
  other concerns about consistency and convention.
 
  That's my opinion. I'll be happy to make the changes if a RM gives me
the green
  light to do so.
 
 The change being proposed was discussed once more in the RM circle and is
being seen as inappropriate.

 The CSPRNG RFC and the implementation was voted. The change being
proposed amends the paradigm of the current language behavior. Currently no
effort has been done do discuss and work out the paradigm change.

 By today's terms, there are other functions which could require throwing
instead of returning false for security reasons. Security being over BC was
and is even in the patch versions, however how it is handled is related to
the hard and deeply internal cases like memory corruption, etc. Having a
decision that a return value is something security related has impact to
the existing behavior. Having different technical requirements to the
congeneric cases on the language level brings inconsistency. Producing
inconsistent behaviors by one case, without any evaluation and clear course
for other cases, without respecting the votes and code freeze is alarming.

 The current timeline doesn't allow for a proper solution of this topic in
7.0. The RMs recommendation is that everyone expressing a strong support in
this thread for the behavior change either for core functions in general or
particularly in the security context stands up for a proper solution in
7.1. If no one believes that a proper solution can exist in 7.1, then an
inconsistency shouldn't exist in 7.0, except the community wants it to be
so which brings it back to an RFC. With respect to everyone who voted on
the original implementation of CSPRNG RFC and everyone else regarding the
topic throwing

Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7

[Anthony Ferrara]

Pierre

On Aug 21, 2015 22:01, Pierre Joye pierre@gmail.com wrote:

 On Sat, Aug 22, 2015 at 8:43 AM, Anthony Ferrara ircmax...@gmail.com
wrote:
  Anatol,
 
  On Aug 21, 2015 8:10 PM, Anatol Belski anatol@belski.net wrote:
 
  Hi,
 
   -Original Message-
   From: Anthony Ferrara [mailto:ircmax...@gmail.com]
   Sent: Friday, August 21, 2015 3:37 PM
   To: Scott Arciszewski sc...@paragonie.com
   Cc: Pierre Joye pierre@gmail.com; Trevor Suarez
   ric...@gmail.com;
   Niklas Keller m...@kelunik.com; PHP Internals 
internals@lists.php.net
   Subject: Re: [PHP-DEV] Recap - Core functions throwing exceptions in
   PHP7
  
   On Fri, Aug 21, 2015 at 6:14 AM, Scott Arciszewski 
sc...@paragonie.com
   wrote:
On Fri, Aug 21, 2015 at 3:52 AM, Pierre Joye pierre@gmail.com
wrote:
On Fri, Aug 21, 2015 at 9:38 AM, Scott Arciszewski
sc...@paragonie.com
   wrote:
On Wed, Aug 19, 2015 at 11:36 AM, Trevor Suarez ric...@gmail.com

   wrote:
Ah, I didn't realize this thread existed. I had just commented
on
the old one, but the point still stands:
   
PHP 7.0 RC1 was just tagged.
Shouldn't this be a relatively high priority to fix/decide so we
don't end up with behavior that can't be fixed until PHP 8.0?
   
On Mon, Aug 10, 2015 at 6:54 PM Niklas Keller m...@kelunik.com
wrote:
   

 Okay, great, we have people on both sides on this
discussion. I
 hope nobody minds if I sit this part out.

 What specifics need to be discussed? Should somebody set up a
 poll? (I don't know how to do that.)
   
   
You can find information on how to setup a poll in step 6 here:
https://wiki.php.net/rfc/howto
   
Regards, Niklas
   
I agree that this should be a relatively high priority. I'm not
sure
what the next steps would be. (Aside: I still have a PR I need to
write that I've been holding off on until the fate of PHP 7's
CSPRNG
feature is determined.)
   
Can we reach some sort of consensus on throw new Exception vs
throw
   new Error?
   
I think the best would be a RFC, not only for the decision itself
but
also to have a clear view about what will be changed or affected.
   
Cheers,
--
Pierre
   
@pierrejoye | http://www.libgd.org
   
Fine, let's do this:
   
1. Violate the feature freeze for this exceptional decision.
2. One of the folks in the camp that WANTS an RFC and a drawn out
formal decision-making process opens it with a poll.
3. Give me voting karma.
   
Let's NOT make the CSPRNG feature fail open. That is an absolutely
terrible idea.
  
   My proposal/stance:
  
   Let's make random_* throw an Exception if it cannot connect to a
random
   source. And let's have it throw an TypeError if ZPP fails, or Error
if
   min = max.
  
   The first two are consistent with existing exceptions.
  
   The third (Error if minmax) is where the contention lies. I'm
   suggesting Error as
   it's consistent with parameter errors in the sense that the type may
be
   correct,
   but the value isn't (hence it's the same kind of error as a parameter
   error, just a
   different sub-classification.
  
   MHO is this is too important of a distinction to simply gloss over.
   Having it return false (or null) will be a problem, as nobody will
   perform the error
   checks. And returning $x where `$x == 0` in a security context could
be
   incredibly
   bad. As such, I think the security implications here outweigh nearly
all
   of the
   other concerns about consistency and convention.
  
   That's my opinion. I'll be happy to make the changes if a RM gives me
   the green
   light to do so.
  
  The change being proposed was discussed once more in the RM circle and
is
  being seen as inappropriate.
 
  The CSPRNG RFC and the implementation was voted. The change being
proposed
  amends the paradigm of the current language behavior. Currently no
effort
  has been done do discuss and work out the paradigm change.
 
  By today's terms, there are other functions which could require
throwing
  instead of returning false for security reasons. Security being over
BC was
  and is even in the patch versions, however how it is handled is
related to
  the hard and deeply internal cases like memory corruption, etc. Having
a
  decision that a return value is something security related has impact
to the
  existing behavior. Having different technical requirements to the
congeneric
  cases on the language level brings inconsistency. Producing
inconsistent
  behaviors by one case, without any evaluation and clear course for
other
  cases, without respecting the votes and code freeze is alarming.
 
  The current timeline doesn't allow for a proper solution of this topic
in
  7.0. The RMs recommendation is that everyone expressing a strong
support in
  this thread for the behavior change either for core functions in
general or
  particularly in the security context stands up for a proper

Re: [PHP-DEV] set_exception_handler catches all Throwables

[Anthony Ferrara]

Stas and all,

On Wed, Aug 19, 2015 at 2:45 PM, Stanislav Malyshev smalys...@gmail.com wrote:
 Hi!

 Actually, I don't call this intended. This is just as much as a BC break
 as the original implementation where Errors where also Exceptions. IMO,
 set_exception_handler() should be changed - with my preference it not
 capturing Error, and instead have an additional set_throwable_handler().

 Could you explain why? As I understand, set_exception_handler() is
 needed to provide a backstop for the cases when all else fails and allow
 for ordered shutdown, nice error message, logging, etc. With this in
 mind, catching all Throwable's is well within this function. So what
 would be the case for having two separate functions for this task and
 what would be the case for using one that only catches half of the
 runaway exceptions (throwables) but not the other half?

This is a very important point that bears repeating. The difference is
that if an exception handler is called, the script *will* terminate
after the handler is called.

The point in separating catch(exception) from catch(throwable) was
that the prior can be done in specific circumstances where the only
reason an exception was thrown was because of a specific failure
(which could be worked around). Adding throwables changes that
contract, and hence was made to not inherit from Exception.

But this case, the exception handler should purely be a logging /
pretty error to user. This isn't a best practice distinction either
because since execution terminates afterwards there isn't much you can
do (you can't even call the exception handler again).

So in this case, I don't really see the distinction here that would
warrant splitting it into separate functions. If it was like
error_handler where you could return false and resume, I'd be 100% on
board. But as it is today, I don't see why separating it would be
beneficial (what's the use-case where you need to split it).

Anthony

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

Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

[Anthony Ferrara]

Matt,

 You are of course welcome to disagree with the overwhelming body of security
 advice that parameterized queries are the correct, secure way to prevent SQL
 injection. In that case, you only need to not enable this feature. This
 feature is off-by-default, and only attempts to help secure webapplications
 and webdevelopers who do (or are required, for example by PCI compliance
 standards) to adopt this security-best-practice to ensure that they do so
 systematically across their entire website.

You seem to misunderstand me. I'm *not* saying that you shouldn't use
parameterized queries. Nor that they are not one of the best tools
available. I am simply pointing out that they are not a sure-fire
one-stop solution. There is a lot more that goes into it than simply
using prepare/bind. As indicated by the two cases I talked about
(structural elements not being supported and implementation quirks) as
well as others (DOS attacks from wildcards in malformed query
parameters, type validation, etc). This is not to say that we should
avoid PQ, but that we should recognize that it's not enough to just
use one thing and forget about everything else.

Anthony

PS: w3schools is NOT w3c. And their content is probably the single
largest source of security vulnerabilities for PHP, so citing them in
a security discussion is more than a little ironic.

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

Re: [PHP-DEV] PHP 7.1 Cryptography Projects

[Anthony Ferrara]

All,

  How about Anthony Ferrara (a board member for the
 Password Hashing Contest)?

For the record, my only involvement with the PHC is as a passive
observer. I am not on the board nor have I been actively involved.

Anthony

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

Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

[Anthony Ferrara]

All,

On Wed, Aug 5, 2015 at 10:40 AM, Julien Pauli jpa...@php.net wrote:
 On Tue, Jul 28, 2015 at 7:33 PM, Matt Tait matt.t...@gmail.com wrote:

 Hi all,

 I've written an RFC (and PoC) about automatic detection and blocking of SQL
 injection vulnerabilities directly from inside PHP via automated taint
 analysis.

 https://wiki.php.net/rfc/sql_injection_protection

 In short, we make zend_strings track where their value originated. If it
 originated as a T_STRING, from a primitive (like int) promotion, or as a
 concatenation of such strings, it's query that can't have been SQL-injected
 by an attacker controlled string. If we can't prove that the query is safe,
 that means that the query is either certainly vulnerable to a SQL-injection
 vulnerability, or sufficiently complex that it should be parameterized
 just-to-be-sure.

 There's also a working proof of concept over here:

 http://phpoops.cloudapp.net/oops.php

 You'll notice that the page makes a large number of SQL statements, most of
 which are not vulnerable to SQL injection, but one is. The proof of concept
 is smart enough to block that one vulnerable request, and leave all of the
 others unchanged.

 In terms of performance, the cost here is negligible. This is just basic
 variable taint analysis under the hood, (not an up-front intraprocedurale
 static analysis or anything complex) so there's basically no slow down.

 PHP SQL injections are the #1 way PHP applications get hacked - and all SQL
 injections are the result of a developer either not understanding how to
 prevent SQL injection, or taking a shortcut because it's fewer keystrokes
 to do it a feels safe rather than is safe way.

 What do you all think? There's obviously a bit more work to do; the PoC
 currently only covers mysqli_query, but I thought this stage is an
 interesting point to throw it open to comments before working to complete
 it.


 I haven't read all the answers to the thread, but the RFC.

 What fools me, is that you want to patch an internal, highly critical used
 concept of the engine : zend_string, just for one use case.

 Everything touching SQL should be independant from the engine.
 Have a look at ext/mysqlnd, that plays with strings and builds a parser on
 top of them to analyze SQL queries. Same for PDO.

 I think such a concept should not be engine global.

I agree with Julien here. There are simply too many permutations of
possible tainted destinations. And too many ways of verifying if
something is actually secure or not.

For example, would taint checking detect ctype_digit() guards? Or
filter_* guards?

But even deeper than that is the fact that there is not just one thing
that a variable could be tainted for. A non-exhaustive list:

- MySQLi
- Postgres
- PDO
- shell_exec
- HTML context output (XSS)
- XML
- URL encoding
- Shell output (STDOUT)
- JavaScript (using MongoDB, etc)
- etc

And there's an *even deeper* problem. Consider the following code:

$name = $_GET['name'];
$escapedName = mysqli_real_escape_string($conn1, $name);
mysqli_query($conn2, SELECT * FROM users WHERE name='$escapedName' LIMIT 1);

Unless you're tieing the taint to specific connections, that is
*possible* to inject under certain circumstances.

Given the complexities, unless a solution can address at least *some*
of these (beyond the trivial cases) I don't know if it belongs in
core.

 Also, patching zend_string will break ABI, and should then not be merged
 until next major, aka PHP8.
 We have now a stable code base, PHP7 is beta, no more ABI breakage and
 every extension recompilation please.

 PHP has always been an extension based language : embed your thoughts into
 extensions, and prevent from hacking the global engine if it is not to
 support a global idea used everywhere.

 Also, we have ext/tainted ; and back in 2006 when PHP5.2 were released,
 such ideas as SQL injection prevention into the engine, were abandonned
 because too specific. We concluded by thinking about PHP as being a general
 purpose language, and high level security such as SQL injection prevention
 should be taken care of in userland, or self-contained in extensions.

Now, if you can create a framework for tainting variables that
extensions can hook into, that's something interesting. Because now
extensions can declare their own taint criteria and requirements, and
have the engine track them. Doing this without sacrificing performance
is going to be tricky, but that would be interesting.

Anthony

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

Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

[Anthony Ferrara]

Matt,

 To be clear: this feature does not track taint through escape functions,
 regular expression filters, ctype_filters and the like by design. Security
 best-practice and more than a decade of security consulting experience show
 that developers who rely on filters and escaping rarely manage to do so
 competently and systematically enough to prevent SQL-injection on
 non-trivial websites. Rather, this feature recognizes that SQL-injection is
 already a solved problem. It is uncontroversial and overwhelmingly accepted
 security best-practice to ensure that every dynamic SQL query is executed
 via a prepared statement rather than via string-escaping.

Except that not every part of a query is preparable. And many
non-trivial complexity websites use these portions of queries
extensively.

Hence a blanket **programming language level** blocking of it is not
really going to fly.

 This feature works best for big websites that are following (or in the
 process of migrating their code to follow) this security-best-practice, as
 it allows them to systematically verify during development that the query
 string to every SQL statement is guaranteed untainted by attackers.

Actually, this allows them to verify at runtime. Not during
development (codepaths that aren't hit at devtime can still cause
problems at runtime).

If this is your goal, I'd suggest doing static analysis to prove (or
not) it. I have a working proof-of-concept of one here:
https://github.com/ircmaxell/php-security-scanner

 In terms of whether this RFC is too coupled with SQL extensions, I am
 sensitive to these concerns, but I don't think they apply for three broad
 reasons:

 Firstly, the taint logic tracks safeconstness (i.e. whether a zend_string
 is a string literal or linear concatenation of string literals), and
 by-design does not attempt to interact with escaping functions because (as
 your example clearly shows), escaping functions only /sometimes/ prevent
 injections, whereas parameterized queries /always/ stop injections.

No they don't. They only stop injections when used correctly. For
example (an edge case, but an important one):
http://stackoverflow.com/questions/134099/are-pdo-prepared-statements-sufficient-to-prevent-sql-injection/12202218#12202218

And that doesn't even touch on the DB backends that don't support PS.
And it doesn't even touch on the fact that not every dynamic part of a
query is preparable.

 reason the taint feature can be trivially applied to any builltin function
 where one parameter is structural and should be constant. It could be
 deployed without modification to prevent injection into regular expression
 queries for example to prevent denial-of-service, or to prove that the
 parameter to shell_exec is constant.

 Secondly, this feature applies globally to all SQL extensions, not just
 mysqli. This feature encompasses protection of mysqli, PDO and Postgres. In
 future, I would like to build this feature out to include some of the other
 categories of injection later, but given that SQL-injections remain the
 single most commonly exploited vulnerability in PHP applications, I think
 starting with them is probably best. Tackling SQL-injection in PHP is a big
 enough task as it is, and is a good place to start.

 Thirdly, although SQL extensions are extensions, this is a technicality, in
 much the same way that Zend Core is not supposed to be coupled to PHP. In
 reality, /most/ non-trivial PHP websites use one SQL extension or another to
 interact with a database, and despite parameterized queries existing for
 over a decade, huge numbers of PHP websites remain vulnerable to them --
 with a devastating impact on the company and their users when the
 vulnerability is exploited.

Except that there are a number of DB extensions that don't ship with
PHP. And those that aren't shipped at all (they are custom propriatary
extensions). And those that aren't really SQL, but use similar
semantics (MongoDB).

 Understanding SQL injections is hard for many junior developers to
 understand, and hard for companies to apply systematically. The impact of
 them getting it wrong can be catastrophic to companies and is a major threat
 to users' online privacy when their data gets compromised. I think having
 PHP give developers a hand to write code that is unambiguously safe from
 hackers would be a good for whole PHP community.

It's hard, because tutorials make it hard. It's hard because we show
concatenation as the right way of doing things, and then tell them
it's wrong. It's hard, because we suck at teaching.

Kent Beck had an awesome passage in his book Test-Driven-Development
By Example. I'll paraphrase here, but he said that every engineer he
worked with found testing difficult. However, his daughter found it
easy and never even thought about it. It was because she was taught
TDD from the ground up. She was taught that you don't write code and
then test, you just test  write code. So she never had time to learn
bad 

Re: [PHP-DEV] PHP 7.1 Cryptography Projects

[Anthony Ferrara]

Lauri,

On Tue, Aug 4, 2015 at 9:12 AM, Lauri Kenttä lauri.ken...@gmail.com wrote:
 On 2015-08-04 14:54, Scott Arciszewski wrote:

 we do not allow secure modes


 I hope that was a typo... ;)

Indeed, it was not.

The concept for this (I've been working with Scott on it) is that this
should be a high-level abstraction. And any good high level
abstraction should make assumptions for its users. One of them is that
they want to be secure.

If you want to build an insecure cipher, the primitives will still
exist (openssl/etc).

 On 2015-08-04 14:54, Scott Arciszewski wrote:

 Version and configuration information (not what is passed, but what is
 used) will be stored in the first few bytes of ciphertext output.


 Will this information be specific to the driver or to PCO, or is it possible
 to use other software for decryption? Will the API have a way to decrypt
 data based on that information (that is, without passing a DSN to the
 constructor)? How about producing a human-readable DSN of the relevant
 and/or all used settings to solve both of these cases?

Rather than human readable (since that would consume a lot of space in
the resulting ciphertext), I'd suggest a formalized open specification
of the storage formats. Similar to the headers used by TLS and other
formats. That way anyone can build to the specification, which would
be maintained along side the implementation.

So something like:

byte 0 : Version identifier

Version 1:
byte 1 : cipher identifier
byte 2 : mode identifier
byte 3 : authmode identifier
byte 4-8 : cipher-specific settings

At least that's my thoughts.

Anthony

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

Re: [PHP-DEV] Exposing object handles to userland

[Anthony Ferrara]

Anatol,

On Mon, Aug 3, 2015 at 10:38 AM, Anatol Belski anatol@belski.net wrote:
 Hi Nicolas,

 -Original Message-
 From: nicolas.gre...@gmail.com [mailto:nicolas.gre...@gmail.com] On Behalf
 Of Nicolas Grekas
 Sent: Monday, August 3, 2015 1:29 PM
 To: Rowan Collins rowan.coll...@gmail.com
 Cc: internals@lists.php.net
 Subject: Re: [PHP-DEV] Exposing object handles to userland

  - more importantly for users, these ids couldn't be compared to
  var_dumps'.
 
  Why do you need to compare the output of two dump functions? Just add
  a note to the documentation that these are not the same IDs.
 

 That's not a strong feature, but still, it makes the tool a little bit more
 comfortable to use.

 Oh, and an other benefit of the handle is that it gives a rough estimation 
 of the
 number of objects created and their instantiation order. When debugging, any
 hints count.

 For VarDumper, I don't need spl_objet_id(). As we spotted, the code is 
 already
 able to get the number it needs.

 Having spl_object_id() is still a feature that is not exposed to userland, 
 but that is
 useful as I tried to demonstrate.

 I'd be on the side of creating new function, too, if it's really needed. And 
 not touching the old one. As mentinod before, maybe some other useful cases 
 could be addressed like immutable strings.

 But with the object id - still, how are the issues mentioned going to be 
 handled?

 - handle gets reused within the same script, even in same request. There's no 
 way to realize an object was garbage collected and completely another one has 
 the same id.\

Well, one way that's handled is by storing a reference to the object.
That way you know it's not collected.

Basically, if you need to store something associated with an object's
id, also store a reference to the object.

This is how it's being done today when people use spl_object_hash()
and associated objects (like SplObjectStorage).

 - what is done in the case the internal implementation was changed, it'll be 
 probably hard to emulate but some apps will already depend on it.

As long as the number returned is unique, it should be pretty straight
forward. The contract isn't that a specific integer is returned, it's
that it's a unique integer. So if object allocation changes the order
that ids are issued, that shouldn't matter.

And in practice we've seen that with a few of the changes in 7. A few
internal tests may fail because they depend on the detail, but that's
because they are bad tests, not the functionality changed.

 Maybe just incrementing a static variable were simple enough :) But IMHO 
 these points need to be addressed prior the implementation. Maybe it's even 
 not reliable enough to rely on the internal implementation.

The problem here is that PHP is used by long-running processes as
well. Imagine a server that runs for weeks. It could over the course
of that time allocate trillions of objects. But since the handle is 32
bit (a signed int actually, which sounds wrong:
http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_objects_API.h#43 ), you
can only have 2 billion objects allocated at one point in time.

Even moving to a 64 bit counter, that's better but is it really
necessary? You'd need to store the counter value for every single
object. Meaning that you add 8 bytes of memory to each object in the
system. Would it be a better experience? Perhaps. Is it necessary? Not
sure...

I support leaving spl_object_hash() as is, and adding a
spl_object_id() which is documented similarly and returns an integer
for each object.

My $0.02 at least

Anthony

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

Re: [PHP-DEV] PHP 7.1 Cryptography Projects

[Anthony Ferrara]

Scott,


On Mon, Aug 3, 2015 at 4:54 PM, Scott Arciszewski sc...@paragonie.com wrote:
 Hi,

 I would like to make it easier for PHP developers to implement
 cryptography features in their applications. I intend to work on some
 of these ideas and submit them for inclusion in PHP 7.1.

 Some of these might be familiar to some of you.

 1. Pluggable Cryptography Frontend

 Work is currently underway for a PHP prototype for this idea
 originally suggested by ircmaxell, that will basically be like PDO for
 cryptography. Our current project name, subject to change, is PHP
 Crypto Objects (PCO).

 The idea is that you could write code like this to add secure
 authenticated encryption to your application without having to worry
 about the details.

 $AES = new \PCO\Symmetric('openssl:cipher=AES-128');
 $ciphertext = $AES-encrypt($plaintext, $someKey);

 $PKC = new \PCO\Asymmetric('libsodium');
 $offlineDecryptable = $PKC-seal($plaintext, $someX25519PublicKey);

 When it's finished, I'd like to turn it into a PECL extension so users
 can play with it in PHP 7.0 and submit it for inclusion in 7.1.

 2. Cache-timing-safe character encoding functions

 Alternatives for existing functions that should function like their
 unsafe counterparts, but without branches or data-based index lookups.

 * hex2bin() - hex2bin_ts()
 * bin2hex() - bin2hex_ts()
 * base64_encode() - base64_encode_ts()
 * base64_decode() - base64_decode_ts()

 Other formats are out of scope, unless someone can make the case that
 we need to support RFC 4648 base32 encoding (e.g. for Tor Hidden
 Service integration).

 3. Other ideas (not yet committed to at all, but might be of interest
 to others):

 * Improving the OpenSSL API, or at least the documentation
 * Adding streaming encryption/decryption support to OpenSSL
 * Adding AE and AEAD interfaces to OpenSSL
 * Aliasing MCRYPT_AES - MCRYPT_RIJNDAEL_128, adding MCYPT_MODE_CTR

 What I need from you is guidance on what features or changes you want
 to see in 7.1 and which can be put off until later (or never proposed
 as an RFC at all).

 Seriously, all I need is your opinion and whether or not you'd like to
 see any of these happen. If you have specific implementation details
 you'd like to discuss or requests, of course those are welcome too. :D

 With great ubiquity comes great responsibility. - Matthew Green
 https://twitter.com/matthew_d_green/status/578567678492733440

Thank you! You have my full support here (and when I get time my
contributions). I think these projects will go a long way towards
improving security in PHP.

so, Thank You!!!

Anthony

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

Re: [PHP-DEV] Core functions throwing exceptions in PHP7

[Anthony Ferrara]

Ferenc,
On Jul 31, 2015 6:34 PM, Ferenc Kovacs tyr...@gmail.com wrote:



 On Tue, Jul 14, 2015 at 11:04 PM, Sammy Kaye Powers m...@sammyk.me wrote:

 Hello lovely PHP nerds,

 There are two open PR's for PHP7 to modify the behavior of the CSPRNG's:

 https://github.com/php/php-src/pull/1397 (main discussion)
 https://github.com/php/php-src/pull/1398

 Currently the random_*() functions will issue a warning and return false
if
 a good source of random cannot be found. This is a potential security
hole
 in the event the RNG fails and returns false which gets evaluated as 0
in a
 cryptographic context.

 To prevent this exploit the proposed behavior will throw an Exception
when
 the RNG fails or certain argument validation fails. This also gives the
 developer a graceful way to fall back to an alternate CSPRNG.

 Since the core functions in PHP don't throw Exceptions, there is debate
on
 whether or not this change should be implemented. Some say the CSPRNG's
 should get a special pass since they will be relied on for cryptography.
If
 we can't throw Exceptions, there were suggestions of raising a fatal
error
 if the RNG fails.

 I think the argument can be boiled down to consistency vs security. We'd
 love to hear your feedback to decide what we should do in this context.
:)

 Thanks,
 Sammy Kaye Powers
 sammyk.me

 Chicago, IL 60604


 I would vote for E_WARNING and return false.
 This can be wrapped in an oop wrapper in userland if somebody prefers and
exception but would still keep the procedural style as first class citizen.
 Plus this would be consistent with other security/crypto related errors
like mcrypt_encrypt() getting an invalid key/iv
 Nikita, Anthony what do you think?

Strong -1 on this.

The consistency point is something to consider, but there are three major
differences between password_* + mcrypt_* and this case.

First, the majority of mcrypt and password functions are single use.
Meaning they are called once and not inside of loops. Random_int on the
other hand will be used in loops and in direct combination with other
functions.

Second, the target audience is different. Mcrypt targets those that know
something about what they are doing. The api is designed that way. Don't
get me wrong, a lot of users have no idea how to use the APIs properly. But
the api is designed such that you need to know it well to use it
effectively. This is a massive fundamental problem with how crypto code was
implemented in php. Things have been changing lately though. Apis are being
designed with end users in mind. Password_hash was one of these, but others
are on their way as well.  In general, the difference is putting the onus
of correct usage on the designer rather than the implementor. Make it
harder to screw up than to do it safe.

Third and lastly, they were built in different times. Had exceptions been
acceptable when I wrote the password functions, believe me I would have
used them. But they weren't just not an option, they were strictly
verboten. Today things are very different with 7. IMHO an exception is the
right way to error here. The problems Scott raises are too big and have too
much potential impact to just leave to the implementors.

Instead, let's follow the trend of not handicapping what's possible. But
instead making it harder to do something wrong than to do it right.

After all, we are not discussing whether an error is appropriate here. We
are discussing whether to fail in a way that forces the user to admit there
was failure, or fail in a way they they can miss (leading to insecurity)...

My $0.02 at least

Anthony


 --
 Ferenc Kovács
 @Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Exposing object handles to userland

[Anthony Ferrara]

Julien,


On Fri, Jul 31, 2015 at 10:23 AM, Julien Pauli jpa...@php.net wrote:
 Hi people.

 I've been pinged many times to add a new spl_object_id() function to PHP,
 that would return the internal object handle of an object.

 Today, spl_object_hash() partially allows that, but adds many randomness to
 the result, which is not very cool to use later  (why does it even add
 randomness ?).

 There has been topics about this subject.
 For example, at http://marc.info/?l=php-internalsm=141814350920452w=2


 Beeing able to get the object handle back in PHP userland would ease many
 tools, mainly debug-oriented tools.
 I know PHPUnit, Symfony and many big projects today make use of
 spl_object_hash() to identify objects.

 I also know people that print_r($an_object) and parse the output just to
 extract the object handle from there... Crazy isn't it ?
 Why couldn't we help those people by simply adding a new function that does
 the job ?

 Thoughts ?


I'm not sure about the randomness to the handle, but the hash also
includes the object handler pointer. So without the random, we'd be
leaking information about the memory layout of the application.

And for the record, I am cool with simply exposing the handle.

Anthony

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

Re: [PHP-DEV] Exposing object handles to userland

[Anthony Ferrara]

Nicolas,

On Fri, Jul 31, 2015 at 2:24 PM, Nicolas Grekas
nicolas.grekas+...@gmail.com wrote:
 Anthony's argument about exposing the mem layout is crucial, though.


 Yes it is!

 The patch I attached un-xors only the part for the object's handle.
 The memory pointer is kept xored.

Just checked the patch, perfect :-)

You have a +1 from me, for what it's worth.

Anthony

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

Re: [PHP-DEV] Disabling External Entities in libxml By Default

[Anthony Ferrara]

Stas,

On Thu, Jul 30, 2015 at 2:57 PM, Stanislav Malyshev smalys...@gmail.com wrote:
 Hi!

 The problem here is that imagine the following:

 I think if we separate the loading the initial file (i.e., staring point
 of the XML parser) and the loading the entities from that file (which is
 not happening right now) we'd solve many BC problems. Not sure about
 SOAP, but many others for sure.

Yeah, that seems reasonable. I'll take a peek at the code to see how
bad it will be to separate it (though I'm not familiar with the xml
extensions much).

 I know that you want it to work, but this is actually a great place to
 fail, because you're loading a trusted resource over HTTP. Meaning
 that an attacker could MITM and inject malicous XML into the response,
 and own your server without even needing to own the endpoint.

 I feel like XML parser is a wrong place to solve this problem, transport
 security can be done in HTTPS, signatures, etc. Otherwise many protocols
 that rely on XML - such as SAML, which is quite widely used - would be
 completely useless.

Yeah, it's a pretty complex problem. I think there should likely be
multiple levels of defense. One level is limiting external entity
requests by default. Another level would be potentially to add a
context option to dom document to allow you to whitelist URLs or
servers.

I think the point would be to document and make it secure by-default,
but provide the ability to turn it back on if you know what you're
doing (though that potentially has a bunch of possible problems as
well).

Anthony

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

[PHP-DEV] Disabling External Entities in libxml By Default

[Anthony Ferrara]

All,

I wanted to float an idea by you for PHP 7 (or 7.1 depending on the
RM's feedback).

Currently, PHP by default is vulnerable to XXE attacks:
https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing

To bypass this, you need to turn off external entity loading:

libxml_disable_entity_loader(true);

What I'm proposing is to disable entity loading by default. That way
it requires developers to opt-in to actually load external entities.

Thoughts?

Anthony

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

Re: [PHP-DEV] Core functions throwing exceptions in PHP7

[Anthony Ferrara]

Rowan,

 This is certainly some people's concern, but Anatol has raised a subtly
 different consistency-related point, which is this:

 Since we have no policy for what kinds of Throwable should be emitted in
 what circumstance, throwing anything in this function sets a precedent which
 will have to be incorporated in any future plan.

 Assuming nobody is fundamentally against ever adding Throwables to core
 functions, there are a minimum number of questions that need to be agreed
 before adding the first one:
 - when should we inherit from Error and when from Exception?

IMHO, Errors signify programmer error, where Exceptions signify
unknown or runtime errors. Meaning that an Error should always be a
problem with your code, but an Exception could be a systems problem, a
user problem or a problem in your code.

While that's slightly off-topic to this discussion, it frames which
type random_* would throw pretty clearly (Exception).

 - is it ever OK to throw a plain Error or Exception (thus forcing users into
 the otherwise bad practice of catching those base classes)?

For now, I think that's a good practice. It doesn't constrain us from
sub-typing down the road (7.1, etc), but it also lets us build the
support in today.

For example, if we throw Exception, in 7.1 we could make it
php\RandomException in 7.1 without issue (all we need to get right is
the hierarchy parent).

 - if not throwing the base class, how specific should sub-classes be? (i.e.
 a framework for defining the hierarchy, not necessarily the hierarchy
 itself)

I think this is something that should be RFC'd for 7.1. I don't think
that limits us here though.

 If we can get agreement on those points in time for 7.0, fine, but time is
 very tight, and the window for such discussions has theoretically closed...

I think the only real agreement we need is Error vs Exception. If we
can agree on one of those, we can do the rest in 7.1 without worrying
about BC...

Anthony

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

Re: [PHP-DEV] json_decode/encode should return full precision values by default

[Anthony Ferrara]

Yasuo,

On Sun, Jul 26, 2015 at 4:20 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
 Hi Jakub,

 On Mon, Jul 27, 2015 at 3:32 AM, Jakub Zelenka bu...@php.net wrote:

 I don't think that this is a bug. Your example is also completely
 unrelated to json because the place when the value is rounded is var_dump
 where it's based on ini precision. You would get the same values with
 json_encode but it's only because it uses the same ini ( precision ).
 Basically it has nothing to do with json_decode.


 OK. Better example.

 [yohgaki@dev PHP-master]$ ./php-bin
 ?php
 $j = '{ v: 0.1234567890123456789 }';
 var_dump(json_encode(json_decode($j)));
 ini_set('precision', 20);
 var_dump(json_encode(json_decode($j)));
 ?


 string(22) {v:0.12345678901235}
 string(28) {v:0.12345678901234567737}

I think you missed the point. Parsing isn't dependent upon precision
setting. Only dumping: http://3v4l.org/48VSt

$j = '{ v: 0.1234567890123456789 }';
$d1 = json_decode($j);

ini_set('precision', 20);

$d2 = json_decode($j);

var_dump($d1, $d2);

//object(stdClass)#1 (1) { [v]= float(0.12345678901234567737) }
//object(stdClass)#2 (1) { [v]= float(0.12345678901234567737) }

Meaning that it's parsed correctly.

There is no bug here.

Anthony

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

Re: [PHP-DEV] Optimizing php_html_entities()

[Anthony Ferrara]

On Tue, Jun 23, 2015 at 10:33 AM, Xinchen Hui larue...@php.net wrote:
 Hey:

 On Tue, Jun 23, 2015 at 7:37 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
 Hi all,

 I'm trying to optimize php_html_entities().
 Since htmlspecialchars()/htmlentities() are sensitive function, I would
 like to ask comments before merge.

 https://github.com/php/php-src/pull/1356

 Current php_html_entities() convert int/float/etc to string, then convert
 it.
 int/float/etc is not required to be escaped. Optimize it by simply
 converting them to string.

 Simple benchmark shows about 60% execution time reduction.

 [yohgaki@dev github-php-src]$ ./php-bin b.php
 Time: 10.484607934952
 [yohgaki@dev github-php-src]$ ./php-bin b.php
 Time: 10.867615222931
 [yohgaki@dev github-php-src]$ ./php.new b.php
 Time: 3.9379420280457
 [yohgaki@dev github-php-src]$ ./php.new b.php
 Time: 4.0694711208344
 [yohgaki@dev github-php-src]$ cat b.php
 ?php
 const LOOP=1;

 $start = microtime(true);
 for ($i = 0; $i  LOOP; $i++) {
 }
 $loop_time = microtime(true) - $start;

 $start = microtime(true);
 for ($i = 0; $i  LOOP; $i++) {
 htmlspecialchars(123456790);
 }
 echo 'Time: '.(microtime(true) - $start - $loop_time).\n;
 But passing an non-string to htmlspecialchars are not common used cases..

 optimize not common used cases... will bring nothing to us..

In addition, this breaks the contract, specifically when using scalar
types. Because you're no longer going to error when the contract is
broken (considering htmlspecialchars is documented as string:string).

Anthony

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

Re: [PHP-DEV] Optimizing php_html_entities()

[Anthony Ferrara]

Yasuo,


 IMHO, escape/unescape/encode/decode/conversion function is better to accept
 any types.
 HTML template may be separated script, but database code etc may not.

 Writing code like

 ?php
 declare(strict_types=1);
 $sql = 'SELECT * FROM '. pg_escape_identifier((string)$table). ' WHERE id '.
 pg_escpae_literal((string)$id).';';
 pg_query($sql);
 ?

 is better to be avoided. i.e. (string) cast before passing parameter.

I agree 100%. Instead, the developer should get an error if the
parameter is not a string. Because it is an error. If you're passing
an array to `pg_escape_identifier`, you have FAR WORSE problems.
Having the function accept anything and return anything (as you're
proposing) would eliminate any ability to detect this problem.

If people blind cast, that's their problem. We shouldn't make it
harder for people to detect problems by blindly accepting anything
under the sun.

 Another example. JSON decode convert numeric to int/float

 ?php
 declare(strict_types=1);
 $data = json_decode($json);
 $str = mb_convert_kana((string) $data['some_data'], 'AKHV');
 ?

 Are we going to enforce users to use (string) casts for conversion functions
 to switch
 strict_types=1?

No, the entire point is to have them actually validate the types.

Anthony

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

Re: [PHP-DEV] RFC - making the Exception class abstract

[Anthony Ferrara]

Kevin,

On Wed, Jun 17, 2015 at 4:41 PM, Kevin Bradwick kevinbradw...@gmail.com wrote:
 Hello!

 This is my first post to the internals list so please forgive me if I have
 not followed the rules precisely!

 I've had an idea to improve how developers use exceptions within PHP. I'd
 like to add an RFC but as per the instructions on the site
 https://wiki.php.net/rfc/howto, I am sending this email first gauge
 reaction as an initial idea.

 The idea is to change the base Exception
 http://php.net/manual/en/class.exception.php class to be abstract. The
 reason for this is to encourage developers to extend it to create meaning
 exceptions or use the standard SPL exceptions. The documentation states
 that it's the base class for all exceptions, which kind of encourages my
 thought process.

 Too many times have I seen developers throwing Exceptions when what they
 really needed was something that gave it context like
 InvalidArgumentException or RuntimeException. Yes, I agree this is
 something to tackle at code review (and I do) but I feel PHP doesn't help
 the situation by making it an instantiatable class. I struggle to think of
 a valid reason where it makes sense to throw the root Exception class.
 Catching the root Exception class is a different matter and there are
 perfectly valid cases for doing it.

 So, what does everyone think? Is it worth me pursing the RFC with full
 details of the idea or am I on my own with this one?

 Many thanks!
 Kevin

Changing the existing Exception class to be abstract would break a
metric ton of code. Simply on that metric alone it would be a hard
sell. I think you'd need an exceptionally strong justification for it,
beyond using typed exceptions is better.

Instead, I think we should solve the problem with education. Perhaps
the documentation can better detail out why devs shouldn't directly
throw exception but instead use typed exceptions...?

My $0.02 at least...

Anthony

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

Re: [PHP-DEV] [RFC] [PHP 7.1] libsodium

[Anthony Ferrara]

Scott,

On Wed, May 20, 2015 at 9:15 PM, Scott Arciszewski sc...@paragonie.com wrote:
 Hi Internals Team,

 I'm sure everyone is really focused (and excited) for PHP 7.0.0 later this
 year, and many of you might not want to discuss what 7.1.x looks like yet.

 The current state of cryptography in PHP is, well, abysmal. Our two main
 choices for handling symmetric cryptography are libmcrypt (collecting dust
 since 2007) and openssl, which lacks a streaming API (e.g. mcrypt_generic)
 and GCM support.

 While mcrypt is slowly decomposing in the corner and code is being
 desperately migrated towards openssl in case a critical vulnerability is
 discovered in the abandonware choice, the libsodium extension has been
 growing steadily. Thanks to Remi, it should soon be compatible with both
 PHP 5.x and 7.x (decided at compile-time). The libsodium library itself has
 landed in Debian 8 and Ubuntu 15.04 and adoption is expected to persist by
 the next Ubuntu LTS is released.

 I think now is a good time to talk about the possibility of making
 libsodium a core PHP extension, depending on where things are when we near
 the 7.1 feature freeze.

 I've just opened an RFC for precisely this purpose:
 https://wiki.php.net/rfc/libsodium

While I definitely do like libsodium and consider it a step in the
right direction, I am hesitant overall. The main reason is precisely
what happened with mcrypt. In that a library goes unmaintained, and
all of a sudden we're stuck using unsupported crypto.

I wonder if a PDO-style approach would be better. Where we can have
multiple pluggable backends, and provide backend-specific
functionality if needed. Targetting a high-level API, not exposing
primitives. Something like:

$enc = new SymmetricEncryption(:cipher=aes128;hash=sha256);
// Use any available backend which can do aes128+sha256 mac
var_dump($enc-encrypt(plaintext, $key));

$enc = new SymmetricEncryption(openssl:cipher=arc4;mode=ctr);
// Use any available backend which can do aes128+sha256 mac
var_dump($enc-encrypt(plaintext, $key));


The concept would be that while parts of the algorithm are
controllable by the end-user (like cipher choice, possibly mode, etc),
we would attempt to prevent insecure usages (no ECB).

If you have a need for custom encryption (web service uses a custom
format), then use primitives yourself (like openssl/mcrypt/etc).

My one issue with libsodium is that if you need NIST compliance, it
does nothing for you (considering it uses XSalsa20+ Poly1305). While
this is an advantage for some, it's a disadvantage for many.

Ideally, I'd like to see a prototype of this library built in PHP that
we can play with prior to making into a PECL extension (and ultimately
proposed for core).

I'd just rather try to get this right, rather than yet another
maybe-good-enough-for-now solution.

Anthony

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

Re: [PHP-DEV] Branching off PHP7 and electing RMs

[Anthony Ferrara]

 a week passed and the Kalle  Anatol option is winning unanimously after 23
 votes so far.
 should we wait another week or would be okay to close the votes and
 announce the RMs so that we can start working on preparing the first alpha?

That seems reasonable to me. There was no real objection that anyone
raised, and support is unanimous on the vote so far. No reason to drag
it out longer than it has to go.

My $0.02

Anthony

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

Re: [PHP-DEV] password_hash() best practices

[Anthony Ferrara]

Leszek,

On Thu, May 7, 2015 at 2:11 AM, Leszek Krupinski leafn...@gmail.com wrote:
 On Wed, May 6, 2015 at 4:00 PM, Nikita Popov nikita@gmail.com wrote:

 It should be further noted that there is no standardized crypt() format for
 PBKDF2 and password_hash() is a crypt-compatible API. As such supporting
 PBKDF2 there would be very problematic. We do already support it in the
 form of hash_pbkdf2() and people who wish to use this method (e.g. due to
 legal restrictions) can use it through this API - I don't see a reason to
 have it in password_hash(), which should only support the recommended
 default use case.
 http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf


 That's true that there's no support for pbkdf2 in crypt. On the other hand,
 the RFC for password_hash stated:

 These hashing APIs will initially be thin wrappers around *crypt()* to
 allow for automatic salt generation and better error checking.

 It says initially - that's why I understood that in the future we can
 diverge from crypt in situations when there's a great new hash we would
 like to use, but it's not supported by crypt (yet or at all).

That was precisely the intention. For that exact reason.

*HOWEVER* (and this is a big however), I think we should avoid doing
that unless *absolutely* necessary. We should strive to build off
standardized crypto. This is good both from an interoperability
standpoint, and the standpoint of relying on cryptographers to set the
standard. We have few if any professional cryptographers on this
list/project, so we should avoid as much as possible inventing our own
(unless absolutely necessary, in which we can elicit the help of
professionals).

 Also, I'm pro-choice ;) We have an extensible API for password_hash(), and
 because people have different needs (like gpu strain in bcrypt or longer
 passwords in pbdkf2) we should provide an option for more experienced
 users, while having reasonable defaults. Yes, advanced users can use hash
 functions directly, but password_* are so nice :)

Well, I'm not sure I agree here. I think the point of password_hash()
is to raise the bottom barrier. I have said multiple times that it is
not a replacement for crypt(3) or other more complicated tools. It's
meant more as a way for non-experts to implement secure code.

If you need to make a different tradeoff, then you can always use a
different library or more advanced use case. I think that
password_hash() should remain simple, with as few choices as possible
(less for users to screw up).

As far as length protection, you can simply pre-hash with sha-512 and
base64_encode the result:

$prehash = base64_encode(hash('sha512', $password, true));
$hash = password_hash($prehash, PASSWORD_DEFAULT, []);

This is also inventing crypto, so I would be extremely wary of
recommending this as a project. If we can get the upstream providers
(specifically the OpenBSD project) to add a crypt(3) format for this
specific case, then we can integrate it into our crypt(3)
implementation, and hence password_hash(). But I would want the
upstream to do it first.

The only algorithm at present that I have seen that today could
replace bcrypt in password_hash is scrypt. However, there are 2
fundamental problems with it: 1) there's no crypt(3) binding or
format. 2) At similar cost settings to what most users use bcrypt at
( 0.1 second runtime), it's been shown to be at best no stronger than
bcrypt, or at worst several times weaker.

There is currently a competition for a new password hashing algorithm:
https://password-hashing.net/ I've been watching it fairly closely,
but many of the algorithms suffer a similar weaker than bcrypt at low
runtime problem. The main reason for this is that they are mainly
targeting different use-cases than password_hash targets. Namely, they
are looking at key derivation and login where you can dedicate a login
server (and hence keep potentially GB of memory persistent for use in
hashing). While these techniques are far superior if you can dedicate
the hardware to them, they don't solve the same problem that we're
solving with password_hash.

We could use scrypt or yescrypt (or a few others) as a next-gen
algorithm, but we'd have to be careful with the settings parameters,
as there's more than just one. And it's really easy to screw up the
settings and make it easier for an attacker. Ideally, I wonder if it's
possible for us to simply proxy from a single setting (give users a
cost setting, and generate an pseudo-ideal set of settings given
that cost).

The bottom line is that I think password_hash needs to stay as simple
as possible. It's not designed to be a full fledged library or set of
primitives. It's designed to be an opinionated library that takes as
much decision away from the user as possible. If you need more
control, use a different library. But for the 98% use-case, that
additional complication simply makes it harder for users to get it
right: 

Re: [PHP-DEV] Add support $object::class

[Anthony Ferrara]

On Mon, Apr 27, 2015 at 7:18 AM, S.A.N ua.san.a...@gmail.com wrote:
 Now this code causes an error PHP 5-7.

 PHP Parse:
 Syntax error, unexpected 'class' (T_CLASS), expecting identifier
 (T_STRING) or variable (T_VARIABLE) or '{' or '$'

 Do not want to use get_class($object)

Why not?

Seriously, why not? ::class was added because there was no easy way to
get from the symbol class name to the string representation of it (you
couldn't pass it to a function, etc since it would look like a
constant). So ::class is a purely compile time construct to turn a
literal classname into a string representation.

However, if you have a variable, there already is a way to do that at
runtime: get_class. What's the problem with that where we need to
further support arbitrary syntax?

Note: I'm not saying we shouldn't add support. I'm just saying that
it's not the same situation as with Bar::class...

Anthony

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

Re: [PHP-DEV] RFC: spl_autoload_register() should provide kind of entity to load

[Anthony Ferrara]

Georges,

On Sat, Apr 18, 2015 at 10:24 AM, georges geol...@gmail.com wrote:
 Hi php internals,

 Currently spl_autoload_register() pass the name of the class entity to the
 first *Callable* argument, but there is now way (as i far i know) to know
 what kind of entity we're looking for.
 -Class ?
 -Interface ?
 -Trait?


 A second argument should be added to the *Callable* function describing
 what kind of entity we're looking for.

 Example:

 ?php

 // function __autoload($class) {
 // include 'classes/' . $class . '.class.php';
 // }

 function my_autoloader($entity, $kind = class) {
// Kind would be: class/interface/trait
include $kind . '/' . $entity . .{$kind}.php;
 }

 spl_autoload_register('my_autoloader');

 // Or, using an anonymous function as of PHP 5.3.0
 spl_autoload_register(function ($entity, $kind = class) {
// Kind would be: class/interface/trait
include $kind . '/' . $entity . .{$kind}.php;
 });

 ?


 In fact i think currently that Autoload is too much class oriented as per
 reading php docs, whereas that php currently allow the autoload of many
 entities. It can really confuse probies php developers :(

 *Pros*:

- -Avoid multiple else if() for testing an existing file to load the
entity.
- -As we now know the type of entity to load, it help reduce I/O
activity, then reduce  timespend.
- -Clarify the code: We now  what the autoloader will load
- -Keep the BC safe


 *Cons*:

- -None


This won't work out of the box due to spl_autoload(). If you use that
default autoloader (by calling spl_autoload_register()), it will
accept an optional second argument as the list of file extensions.
Which means that having spl_autoload_register() pass a second argument
to autoloaders will break the existing core autoloader. Changing the
core autoloader is also not really possible due to BC considerations.

So technically, without introducing a new autoload API, this won't
really be possible.

As far as the feature, I would question why you need to distinguish
the file by the type. The names are in the same symbol table, so you
couldn't possibly have a collision. From there, is the identification
of the type of the definition in the filename that important? Isn't
that just another form of Hungarian Notation?

Anthony

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

Re: [PHP-DEV] Concern around growing complexity in engine - hash table specifically

[Anthony Ferrara]

Julien,
On Apr 9, 2015 7:52 AM, Julien Pauli jpa...@php.net wrote:

 On Thu, Apr 9, 2015 at 1:01 PM, Dmitry Stogov dmi...@zend.com wrote:



 On Thu, Apr 9, 2015 at 1:35 PM, Julien Pauli jpa...@php.net wrote:

 On Wed, Apr 8, 2015 at 10:55 PM, Dmitry Stogov dmi...@zend.com wrote:

 On Fri, Apr 3, 2015 at 9:57 PM, Anthony Ferrara ircmax...@gmail.com
wrote:

  All,
 
  I spent a little bit of time today trying to debug an issue with 7
  that Drupal 8 was facing, specifically regarding an array index not
  behaving correctly ($array[key] returned null, even though the key
  existed in the hash table).
 
  I noticed that the hash table implementation has gotten orders of
  magnitude more complex in recent times (since phpng was merged).
 
  Specifically, that ardata and arhash are now the same block of
memory,
  and that we're now doing negative indexing into arData to get the
hash
  map list. From Dmitry's commit message, it was done to keep the data
  that's accessed most often in the same CPU cache line. While I am
sure
  that there are definitive performance gains to doing this, I do worry
  about the development and debugging costs of this added complexity.
 
  As well as the way it increases the busfactor of the project.
 
  There is definitely a tradeoff there, as the change is pretty well
  encapsulated behind macros. But that introduces a new level of
  abstraction. But deeper than that it really makes debugging with gdb
a
  pain in the neck.
 
  Without hard data on this particular patch, I'm not suggesting we
roll
  back the change or anything. I more just want to express concern with
  the trend lately to increase complexity significantly on developers
  for the sake of performance.
 

  While I'm definitely not saying performance doesn't matter, I also
  think performance at all costs is dangerous. And I wonder if some of
  the more fundamental (even if isolated) changes such as this should
be
  way more documented and include the performance justification for
  them. I'm definitely not suggesting an RFC, but perhaps some level of
  discussion should be required for these sorts of changes...
 


 I agree with Anthony.

 Many things however can be solved with a nice .gdbinit.
 We already have dump_ht() , dump_htptr() , f.e , that I'm using
heavilly to debug HT in PHP5.
 Not talking about dump_bt().

 I think one step is to improve our .gdbinit with many more features,
and obviously port the actual ones to work with PHP7.

 A second step is documentation.

 Anthony, you know about our project phpinternalsbook.com, don't you ;-)
 There has been recent discussions on IRC to actually merge this project
under php.net.

 I'm really feeling enthusiast about helping or even taking the lead of
such a project : I would like php.net to hold a real, detailed
documentation about internals.

 I think with PHP7 should come an internal documentation, somewhere
behind php.net , that will explain to a C-aware developper our main
internal structures and choices, especially about performance
optimisations.

 Have you had a look at the new Zend Memory Manager ? It has become
insanely complex, with many performance-turned code.
 Same, but in a lower footprint, for the executor : the executor stack
frame has really changed from PHP5's one, and is also not very easy to
debug (with a long alloced buffer shrinked with many pointer tricks that
needs you to have a complete image of the memory buffer in your head).

 I won't be able myself to document all those tricks, because I'm not
the author of them.
 I think Zend, through Dmitry, Nikic, Bob or Laruence , should help us
understanding some concepts, if they are not around to help with the doc.


 Hi Julien,

 It would be great, if you lead PHP-7 internals documentation project.
 You are always welcome with questions about implementation details.


 Yes I know that you - as well as other guys I talked about in my last
post - are really open and answer quickly and efficiently to our technical
questions, which is a nice point.

 I'm OK to take the lead of such a project.
 However, as PHP itself, the project should stay wide open and everyone
may have something to say/bring.

 Perhaps time to start a thread about this ?

+1 from me. That would go a long way towards mitigating some of these
issues.

Anthony

Re: [PHP-DEV] password_hash() deprecate salt option - thoughts?

[Anthony Ferrara]

I gave it some additional time in case others raised concern.

I have since merged the deprecation of the salt option to password_hash()

Thanks!

Anthony

On Wed, Apr 1, 2015 at 2:26 PM, Anthony Ferrara ircmax...@gmail.com wrote:
 All,

 I've added a PR for this: https://github.com/php/php-src/pull/1213

 Please review the implementation and the wording (as well as the behavior).

 I plan on merging this on Friday if there is no objection (as it seems
 the support has already been unanimous with no hesitation).

 Thanks!

 Anthony

 On Tue, Mar 31, 2015 at 6:21 PM, Ángel González keis...@gmail.com wrote:
 No objections here either.


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


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

RE: [PHP-DEV] Concern around growing complexity in engine - hash table specifically

[Anthony Ferrara]

Fancois,
On Apr 9, 2015 10:16 AM, François Laupretre franc...@php.net wrote:

  De : Anthony Ferrara [mailto:ircmax...@gmail.com]
 
  If we were using a pure abstraction (only accessing the hash table
  information through the public API), then fine because it's isolated.
  However, many extensions and even places in core access hash table
  structure directly (as can be seen by the updates needed by
  https://github.com/php/php-
  src/commit/2b42d719084631d255ec7ebb6c2928b9339915c2).
  Meaning the complexity isn't encapsulated.

 IMHO, that's the main problem. If a piece of code is accessed through an
official published API only, its internal complexity can grow, provided the
API still provides the same services. So, the first step should be to
define and publish an 'official' full-featured API.

We already have one. The public API defined in zend_hash.h (all methods and
macros not prefixed with _).

And my argument would be if code outside of zend_hash.(c|h) needs to access
the internal hash table structure for anything (a public API doesn't serve
the needs), then a new macro or API should be introduced for that use-case
(so that it doesn't need to access the structure anymore).

Anthony

Re: [PHP-DEV] Exception message cleanup

[Anthony Ferrara]

Nikita,

On Apr 9, 2015 8:56 AM, Nikita Popov nikita@gmail.com wrote:

 On Thu, Apr 9, 2015 at 12:33 PM, Niklas Keller m...@kelunik.com wrote:

  Hi Nikita,
 
  I like the new display format, but there's one thing I miss. If you
  replace the exception name for warnings and fatals, how does a user know
  which exception he has to catch?
 
  Regards, Niklas
 
 Sorry, I don't understand what you mean here. The first part of the
message
 says which exception you need to catch, right?

 Nikita

I think he means something greppable in the output. So prefix the exception
name in your custom message with Uncaught  so people can search the
output for Uncaught \w+

+1 on the change overall (with a Uncaught prefix before the exception
classname).

Anthony

Re: [PHP-DEV] Concern around growing complexity in engine - hash table specifically

[Anthony Ferrara]

Andi,



On Tue, Apr 7, 2015 at 8:52 PM, Andi Gutmans a...@zend.com wrote:
 On Fri, Apr 3, 2015 at 11:57 AM, Anthony Ferrara ircmax...@gmail.com
 wrote:

 All,

 I spent a little bit of time today trying to debug an issue with 7
 that Drupal 8 was facing, specifically regarding an array index not
 behaving correctly ($array[key] returned null, even though the key
 existed in the hash table).

 I noticed that the hash table implementation has gotten orders of
 magnitude more complex in recent times (since phpng was merged).

 Specifically, that ardata and arhash are now the same block of memory,
 and that we're now doing negative indexing into arData to get the hash
 map list. From Dmitry's commit message, it was done to keep the data
 that's accessed most often in the same CPU cache line. While I am sure
 that there are definitive performance gains to doing this, I do worry
 about the development and debugging costs of this added complexity.

 As well as the way it increases the busfactor of the project.

 There is definitely a tradeoff there, as the change is pretty well
 encapsulated behind macros. But that introduces a new level of
 abstraction. But deeper than that it really makes debugging with gdb a
 pain in the neck.

 Without hard data on this particular patch, I'm not suggesting we roll
 back the change or anything. I more just want to express concern with
 the trend lately to increase complexity significantly on developers
 for the sake of performance.

 While I'm definitely not saying performance doesn't matter, I also
 think performance at all costs is dangerous. And I wonder if some of
 the more fundamental (even if isolated) changes such as this should be
 way more documented and include the performance justification for
 them. I'm definitely not suggesting an RFC, but perhaps some level of
 discussion should be required for these sorts of changes...

 Thoughts?


 I think it is generally true that increased performance often requires more
 sophisticated approaches.
 Generally speaking I've observed that the faster, more modern runtime
 engines all need to deal with that additional sophistication.
 JIT runtime engines typically are the worst because they deal with hundreds
 of micro-optimizations around code generation (register allocation, cache
 line optimization, etc...).
 So what you have in PHP 7 today is actually not that bad compared to some
 of the other runtimes (IMO).
 I think it can be partially addressed in a combination of documenting key
 datastructures (some of which was already written) and maybe some additional
 comments in areas of code where the complexity level goes up for some very
 specific tricks.

 You can see by the level of interest in performance (whether ones opinion is
 that this is fully warranted or not) around PHP 7, HHVM and other languages,
 that this is an area we need to invest in on an ongoing basis. And
 sophistication will likely go up.

Thanks for the reply. I'm not really saying everything needs to be
dead simple. Most of the issues I'm more talking about could be solved
through communication, documentation, tooling and refactoring. But
some I do question at a more fundamental level. The hash table is one
of them.

If we were using a pure abstraction (only accessing the hash table
information through the public API), then fine because it's isolated.
However, many extensions and even places in core access hash table
structure directly (as can be seen by the updates needed by
https://github.com/php/php-src/commit/2b42d719084631d255ec7ebb6c2928b9339915c2).
Meaning the complexity isn't encapsulated.

Sophistication is fine. What worries me though is magic. What worries
me is the growing inability to debug with normal tools. Perhaps we
need a GDB extension to provide tooling for common debugging tasks.
Heck, even dumping a zend_string requires a cast (p (char*)str-val).

I am all for the performance improvements. I just don't think at all
costs is a viable model (nor do I think that's what people are
doing). I just think it's worth discussing (and hopefully mitigating)
the costs of them explicitly. At least for the more significant ones.

Anthony

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

[PHP-DEV] Concern around growing complexity in engine - hash table specifically

[Anthony Ferrara]

All,

I spent a little bit of time today trying to debug an issue with 7
that Drupal 8 was facing, specifically regarding an array index not
behaving correctly ($array[key] returned null, even though the key
existed in the hash table).

I noticed that the hash table implementation has gotten orders of
magnitude more complex in recent times (since phpng was merged).

Specifically, that ardata and arhash are now the same block of memory,
and that we're now doing negative indexing into arData to get the hash
map list. From Dmitry's commit message, it was done to keep the data
that's accessed most often in the same CPU cache line. While I am sure
that there are definitive performance gains to doing this, I do worry
about the development and debugging costs of this added complexity.

As well as the way it increases the busfactor of the project.

There is definitely a tradeoff there, as the change is pretty well
encapsulated behind macros. But that introduces a new level of
abstraction. But deeper than that it really makes debugging with gdb a
pain in the neck.

Without hard data on this particular patch, I'm not suggesting we roll
back the change or anything. I more just want to express concern with
the trend lately to increase complexity significantly on developers
for the sake of performance.

While I'm definitely not saying performance doesn't matter, I also
think performance at all costs is dangerous. And I wonder if some of
the more fundamental (even if isolated) changes such as this should be
way more documented and include the performance justification for
them. I'm definitely not suggesting an RFC, but perhaps some level of
discussion should be required for these sorts of changes...

Thoughts?

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

Re: [PHP-DEV] password_hash() deprecate salt option - thoughts?

[Anthony Ferrara]

All,

I've added a PR for this: https://github.com/php/php-src/pull/1213

Please review the implementation and the wording (as well as the behavior).

I plan on merging this on Friday if there is no objection (as it seems
the support has already been unanimous with no hesitation).

Thanks!

Anthony

On Tue, Mar 31, 2015 at 6:21 PM, Ángel González keis...@gmail.com wrote:
 No objections here either.


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


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

Re: [PHP-DEV] Overwrite return type-hint into a more specific one

[Anthony Ferrara]

Marc,


On Wed, Apr 1, 2015 at 2:46 PM, Marc Bennewitz dev@mabe.berlin wrote:
 Hi internals,

 On experimenting with return type-hints I noted an inconsistency on
 overwriting an existing hint to a more specific one. On adding a non
 existing return type-hint on overwrite it's fine but it's logically the same
 (this previously was an E_STRICT).

 http://3v4l.org/YdB8s - works fine (E_STRICT lower then php7@20150401)
 http://3v4l.org/UDk0n - Fatal error: Declaration of Bar::setTest() must be
 compatible with Foo::setTest($test): Foo
 http://3v4l.org/AuOsr - HHVM works fine

That's the concept of Variance:
https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)

Specifically, that return types can be covariant (subtypes can
narrow return types) and parameters can be contravariant (subtypes
can widen paramters). So this is valid:

class A extends B {}

class C {
public function foo(A $b): B {}
}

class D extends C {
public function foo(B $b): A {}
}

In that everything that C::foo accepts, D::foo accepts, but D::foo can
accept more.

And D produces more strictly (in that anything that can work with a
product of C::foo can work with what D::foo produces).

We looked into doing this for return types (and all other
declarations). However, we ran into some non-trivial problems around
compilation.

Currently, types are never loaded from a declaration. They are only
loaded when instantiated. Therefore, it's completely possible to have
a declared class with undeclared type declarations. If the type
declaration remains undeclared when you call the method, it's by
definition a failed type (since `$obj instanceof UndefinedClass` is
always false).

If we want to check variance, we need to know about the type at
compile time. This brings up an issue that basically makes it
impossible to separate code into multiple files without an autoloader.
For example:

?php // a.php
class A {
public function foo(B $bar) {}
}

?php // b.php
class B {
public function bar(A $foo) {}
}

You couldn't have that be possible without an autoloader, since
there's a circular dependency. Sure, we could (and should) special
case the doesn't inherit situation, but it's pretty trivial to make
a new example which requires an autoloader.

So that leaves us with a weird situation: to support the feature (in
general), you'd have to use an autoloader or put everything into a
single file. That may be OK, but it's also added complexity.

To the best of my knowledge, Levi removed variance from the proposal
to keep it simple (just like nullables weren't in the proposal):
https://wiki.php.net/rfc/return_types#variance_and_signature_validation

If you'd like to create a proposal for 7.1 to add variance support to
type declarations, I think that would be awesome. It's not terribly
difficult, but there are some gotchas (especially around opcache
support) and non-trivial tradeoffs involved.

Anthony

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

Re: [PHP-DEV] Naming of 'weak' type hints

[Anthony Ferrara]

Pavel,

 Hello,

 I would definitely stick with weak; it is common naming used across
 many languages and textbooks.

 Also, why is the strongly typed mode named strict anyways? If
 anything should change, it should be strict to strong, so PHP doesn't
 look like a special snowflake.

Strong has a very specific meaning, which PHP is not using. For
example, Python variables are strongly typed (meaning it's restrictive
about how types are intermingled). So while x + 3 in JavaScript
(another weakly typed language) is x3, in python it would be a type
error (assuming x + 3).

PHP's overall type behavior is still weak at the variable level. The
difference is that strict type declarations require types to match at
the point of parameter passing. But it doesn't make the variable
strongly typed.

As far as weak, that's the description of the type system in
general. However as far as type declarations are concerned, I think it
would be fair to talk about the two modes as coercive and strict.

Anthony

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

[PHP-DEV] password_hash() deprecate salt option - thoughts?

[Anthony Ferrara]

All,

Ever since we introduced password_hash() in 5.5, I've been watching
its usage as much as possible. I've setup google alerts and such, as
well as auditing implementations I've found on github to try to
understand how it's used.

One thing has become abundantly clear to me: the salt option is
dangerous. I've yet to see a single usage of the salt option that has
been even decent. Every usage ranges from bad (passing mt_rand()
output) to dangerous (static strings) to insane (passing the password
as its own salt).

I've come to the conclusion that I don't think we should allow users
to specify the salt. The crypt() API still exists if users have a need
to generate their own salt. Having it in the simplified API is simply
adding a risk factor without any significant justification.

So I'd like to hear your thoughts about raising E_DEPRECATED when the
salt option is specified in 7.0, with ultimately removing the option
in a later version.

Additionally, I know this is after the RFC freeze deadline, so if you
want to postpone the deprecation to 7.1, that's fine. I just think
it's worth discussion (and if there's consensus to put it in 7.0, then
great).

Thanks,

Anthony

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

[PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5

[Anthony Ferrara]

All,

Voting has been closed on the scalar type declarations v0.5 RFC:

https://wiki.php.net/rfc/scalar_type_hints_v5

At a final score of 108:48, it has been accepted for PHP 7.

Thank you.

Anthony

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

[PHP-DEV] Voting irregularities

[Anthony Ferrara]

All,

I ran some numbers on the current votes of the dual-mode vote right
now. There were a number of voters that I didn't recognize. So I
decided to pull some stats.

The following voters never voted before the dual-mode RFC went up:

dom - no
eliw - no
kguest - yes
kk - no
nohn - no
oliver - yes
richsage - yes
sammywg - no
spriebsch - no
srain - no
theseer - no
zimt - no

Some of these names I recognize from list (sammywg and eliw), but many I do not.

The interesting thing happens when you look at the voting direction.

Currently, the RFC is slightly losing 70:37 (65.4%).

If we look at percentages, 4.2% of yes voters have never voted in a
prior RFC. But a whopping 24.3% of no voters have never voted before.

If we adjust the votes to remove these never voted accounts, it
stands at 67:28. Which is 70.5%. Which is basically where the vote was
prior to the competing RFC opening.

I'm not saying that all of these are bad votes. Nor that they
shouldn't be counted. I think it does raise a significant question
around the voting practices.

Something that I think we need to discuss as a group.

So consider that discussion open.

Anthony

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

Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types

[Anthony Ferrara]

Zeev,

On Sun, Mar 15, 2015 at 3:07 PM, Zeev Suraski z...@zend.com wrote:
 -Original Message-
 From: Pádraic Brady [mailto:padraic.br...@gmail.com]
 Sent: Sunday, March 15, 2015 9:00 PM
 To: Zeev Suraski
 Cc: Bob Weinand; PHP Internals
 Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types

 On 15 March 2015 at 16:55, Zeev Suraski z...@zend.com wrote:
  Bob,
 
  Thanks for the update.  This time, though, although I completely
  respect your decision not to put your RFC into a vote unless the Dual
  STH mode fails, I'd like to either (with your permission) take over
  the RFC or propose my own copy and move it to voting as soon as
  allowed.  This, under a commitment that if I see that Basic STH is
  failing to garner a clear majority, I'll retract it and move to
  support the Dual STH RFC instead for the sake of unity.

 No one individual has the right to break the existing rules around voting.
 There has been more than sufficient time to date to rewrite the voting
 rules,
 debate voting rights, extend PHP7's deadline, or propose the basic RFC so
 described. A vote in contravention of the voting rules at the last
 possible
 minute cannot, by definition, be recognised at this time. I wouldn't even
 vote
 since it might lend it an air of ill deserved legitimacy, forgetting for a
 moment whether a few PEAR contributions make me any more deserving of
 a vote than others.

 No rule is being broken.

 The PHP 7 timeline RFC (wiki.php.net/rfc/php7timeline) states the following:
 Line up any remaining RFCs that target PHP 7.0.   | Now - Mar 15 (4+
 additional months)

 As Bob pointed out, what 'Line up' means - whether it means vote ends, vote
 begins, or discussion begins - is completely open to interpretation.  I
 don't remember what I meant when I wrote it, but arguably, 'line up' is a
 lot closer to 'start discussing' than 'finish voting', and as is typically
 the case when something is unclear, the most lax interpretation is
 acceptable.

By your own words: http://marc.info/?l=php-internalsm=142451267910615w=2

 Following Adam's analysis of the timeline, taking the more 'strict' (no pun 
 intended!) interpretation of the timeline RFC, we still have until tomorrow 
 to start the discussion and still target it for 7.0, no?  Given the 
 importance of this topic, I'd go for the more lax interpretation that allows 
 for votes to begin by March 15, giving us all a bit more time to discuss.

**votes to begin by March 15**. That was the interpretation you used a
month ago.

Anthony

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

Re: [PHP-DEV] [RFC] Basic Scalar Types

[Anthony Ferrara]

Zeev,

 Zeev, allow me to understand how this goes. Bob's discussions on the RFC
 started 2 days ago. Based on the current rules, the RFC can only go to
 vote
 after 2 weeks. That means in 12 days starting now.

 So we are either violating the RFC rules by pushing the vote tomorrow or
 we're delaying PHP7 for another 2 weeks maybe yet another TH RFC passes?

 Bob's RFC is effectively Andrea's v0.1 RFC which was discussed in detail and
 introduced well over two weeks ago.
 I hope we're not going to go into more and more extremes of playing a law
 firm and not an OS project.

We have minimum discussion periods for a reason. To allow people the
time to review proposals as much as to discuss them.

On the surface, yes, this looks like Andrea's 0.1 RFC. However, after
looking at it, it's definitely different. There's a very significant
behavior difference between the two:

Andrea's RFC had the following wording:

 The only exception to this is the handling of NULL: in order to be consistent 
 with our existing type hints for classes, callables and arrays, NULL is not 
 accepted by default, unless the parameter is explicitly given a default value 
 of NULL. This would work well with the draft Declaring Nullable Types RFC.

This proposal has a different behavior here. It explicitly allows
nulls for types:

function foo(int $abc) { var_dump($abc); }

Unlike my proposal and any of Andrea's, calling foo(null) will be
int(0) instead of an error.

This is an important distinction as it basically undermines any
attempt at a nullable RFC, since it makes primitives implicitly
nullable.

So it's not effectively the original proposal. It does differ in a
very significant detail. This is why we have mandatory discussion
periods. Not for playing law firm but for being fair to each other.

Anthony.

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

Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types

[Anthony Ferrara]

Zeev,

 Thus, I deny your request and strongly urge you to *not* fork my RFC.
 That
 would be sabotaging of Anthony's and my RFC.
 I won't tolerate that.

 Anthony welcomed competing RFCs, and in fact proposed it.  I don't see how
 it would be sabotaging your RFC - when in fact it gives it a chance to
 pass in a case Dual Mode manages to garner.

I welcomed competing RFCs according to the accepted process **a month
ago** (http://marc.info/?l=php-internalsm=142383869529695w=2). I
even extended voting on my RFC as a show of good faith. Please don't
abuse that good faith to political ends.

Anthony

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