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

> On Sep 28, 2015, at 3:29 AM, S.A.N wrote:> > Are > there any future plans for - async/await?> This need to know now, not to use > these words to constants, and class names...> > -- > PHP Internals - PHP > Runtime Development Mailing List> To unsubscribe, visit: >

[PHP-DEV] Re: HTTP/2 and Websocket support in 7.x versions

HTTP/2 is entirely outside the scope of the PHP web SAPI as it currently exists. The protocol impacts the actual HTTP server and has nothing to do with the SAPI runtime which is simply handed information about the HTTP request once the server parses it. The protocol used to communicate those

[PHP-DEV] Re: HTTP/2 and Websocket support in 7.x versions

On Tue, Mar 31, 2015 at 10:11 AM Grégory Planchat greg...@luni.fr wrote: Le 31/03/2015 15:56, Daniel Lowrey a écrit : HTTP/2 is entirely outside the scope of the PHP web SAPI as it currently exists. The protocol impacts the actual HTTP server and has nothing to do with the SAPI runtime

[PHP-DEV] Re: Re: HTTP/2 and Websocket support in 7.x versions

this ain't exactly true. Currently in MT environment the task of data separation is pushed to the TSRM by using TLS. Now, if TSRM is reimplemented in a fashion that the data is not stored by using TLS but other mechanism and cooperative multitasking is not something that can't be done. The

[PHP-DEV] [RFC][Accepted] Generator Delegation

Voting concluded yesterday on the Generator Delegation RFC; the proposal passed 25-0 for inclusion in PHP7. https://wiki.php.net/rfc/generator-delegation#vote Thanks to everyone who read the proposal and contributed either directly or indirectly. -Daniel

[PHP-DEV] [RFC RESULT] Generator Return Expressions

The Generator Return Expressions RFC vote has concluded with the following results: YES: 32 NO: 0 https://wiki.php.net/rfc/generator-return-expressions#vote Thank you again to everyone who took time to read and consider the proposal. The associated patch will be merged into master in the

Re: [PHP-DEV] [VOTE] Generator Delegation

On Sun, Mar 15, 2015 at 3:56 PM, Damien Tournoud d...@damz.org wrote: Hi Daniel, In the formal definition, you have: $throw $e; ... which I assume is a typo? Damien Woops! Yes, this is a typo. Thanks for the heads-up; fixing now ...

Re: [PHP-DEV] [VOTE] Generator Delegation

On Sun, Mar 15, 2015 at 4:39 PM, Damien Tournoud d...@damz.org wrote: On Sun, Mar 15, 2015 at 9:35 PM, Daniel Lowrey rdlow...@php.net wrote: This is actually a *vastly* inferior solution to language-level support for generator returns. greenlet/gevent does it this way because these libraries

[PHP-DEV] [VOTE] Generator Delegation

Hi folks! As the discussion period has reached its conclusion I'd like to announce a two week voting period on the Generator Delegation RFC here: https://wiki.php.net/rfc/generator-delegation Voting ends Sunday, March 29. I know everyone is busy and your time is valuable; thanks for spending a

Re: [PHP-DEV] [VOTE] Generator Delegation

On Sun, Mar 15, 2015 at 4:13 PM, Damien Tournoud d...@damz.org wrote: Hi Daniel, Would you mind clarifying the relationship between the Generator Delegation RFC and the Generator Return Expressions RFC? Sure, thanks for the question. As mentioned in the RFC: In short: generator delegation

[PHP-DEV] [RFC PRE-VOTE] Generator Delegation

Hi, internals! The Generator Delegation RFC has been updated significantly and marked as v0.2.0: https://wiki.php.net/rfc/generator-delegation There now exists a final patch and the proposed syntax has been changed from yield * expr to yield from expr I encourage all interested

[PHP-DEV] [RFC VOTE] Generator Return Expressions

Hi, internals! I'd like to announce voting for the Generator Return Expressions RFC: https://wiki.php.net/rfc/generator-return-expressions#vote As this is a fairly concise and straightforward proposal the voting period will last only one week. A two-thirds majority is required for acceptance.

Re: [PHP-DEV] [RFC Discuss] Generator Delegation

Rowan Collins wrote on 02/03/2015 14:44: Could you explain a bit more about how the generator return functionality is necessary for this? It seems to me like it's still just a nice to have, and that the main functionality - delegating from one generator to another - is completely separate. Or

Re: [PHP-DEV] [RFC Discuss] Generator Delegation

On Mon, Mar 2, 2015 at 1:34 AM, Patrick Schaaf p...@bof.de wrote: Am 02.03.2015 00:52 schrieb Daniel Lowrey rdlow...@php.net: I'd like to initiate discussion on a proposal to implement generator delegation via the following new syntax inside generator functions: yield * expr

Re: [PHP-DEV] [RFC Discuss] Generator Delegation

From initial discussions it seems prudent to modify the Generator Delegation RFC to use either of: - yield from expr - yield use expr The `yield from` form would add a single T_YIELD_FROM token (as opposed to a new from reserved word). The `yield use` form would reuse existing keywords. I'd

[PHP-DEV] [RFC Discuss] Generator Delegation

Hi folks, I'd like to initiate discussion on a proposal to implement generator delegation via the following new syntax inside generator functions: yield * expr The Generator Delegation RFC is available here: https://wiki.php.net/rfc/generator-delegation This proposal is conceptually

[PHP-DEV] [RFC Announce] Generator Return Expressions

Hi folks :) I know everyone is already quite busy attempting to resolve scalar types, assertions, etc. So let me add another RFC to your pre-feature-freeze cognitive overload! This proposal allows the specification of and access to Generator return expressions:

Re: [PHP-DEV] Re: I quit.

On Mon, Feb 16, 2015 at 11:00 AM, Arvids Godjuks arvids.godj...@gmail.com wrote: This bickering already jeopardized the type hinting RFC's how many times? 3 as I recall? Zeev was kind enough to reach out privately prior to your message and we began exchanged mails trying to better understand

[PHP-DEV] Re: I quit.

The 0.1 RFC version was mentioned a lot as a good compromise by many people and had major support. People keep saying this like it's a thing, but I and others are vehemently opposed to this as a solution. The only thing weak hints accomplishes is the illusion of safety without actually

Re: [PHP-DEV] Re: I quit.

On Mon, Feb 16, 2015 at 10:19 AM, Zeev Suraski z...@zend.com wrote: -Original Message- From: rdlow...@gmail.com [mailto:rdlow...@gmail.com] On Behalf Of Daniel Lowrey Sent: Monday, February 16, 2015 5:13 PM To: internals@lists.php.net Subject: [PHP-DEV] Re: I quit

Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http

On Wed, Feb 11, 2015 at 5:16 PM, Michael Wallner m...@php.net wrote: On 06/02/15 17:44, Daniel Lowrey wrote: If you doubt that this is a solved problem in userland consider the performance of my own 100% userland HTTP client demonstrated here without the use of curl or any other extensions

Re: [PHP-DEV] Re: Security changes in PHP 7

On Sun, Feb 8, 2015 at 12:11 PM, Tom Worster f...@thefsb.org wrote: Thanks Damien and Daniel for the info. I am not concerned about running out of entropy. I am concerned about userspace RNGs such as OpenSSL http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ Just to be

[PHP-DEV] Re: Security changes in PHP 7

On Sun, Feb 8, 2015 at 4:24 AM, Tom Worster f...@thefsb.org wrote: 3. Will the OpenSSL ext remain as it currently stands? There has been talk of replacing it with a more generic implementation that can swap out the underlying components so we aren't dependent upon a single library. The crypto

Re: [PHP-DEV] Re: Security changes in PHP 7

On Sun, Feb 8, 2015 at 2:18 PM, Tom Worster f...@thefsb.org wrote: On 2/8/15, 12:52 PM, Daniel Lowrey rdlow...@php.net wrote: On Sun, Feb 8, 2015 at 12:11 PM, Tom Worster f...@thefsb.org wrote: Thanks Damien and Daniel for the info. I am not concerned about running out of entropy. I am

[PHP-DEV] Re: Design by Contract

First, let me say that I have voted against the current scalar types RFC. Please do not let that color your evaluation of the rest of this message ... I want to go on record (for the n-th time) as being unhappy about any proposal that forces me to use php.ini. IMHO if it doesn't work with `$ php

Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http

I’ve rewritten the RFC for pecl_http and hopefully addressed most of the things mentioned previously. I you still find anything lacking, please let me know, so I can expand the RFC accordingly. And of course, everything else is up for discussion. I may not have been clear before, but just

Re: [PHP-DEV] Re: OpenSSL ext. improvements for authenticated cipher modes.

The extra params aren't really _that_ bad. Okay, I'd like to reset the conversation a bit here. It's clear that the current API does not fit the problem domain very well. Tacking on more parameters only creates a bigger mess. Six parameters to a stateless function call is a completely incoherent

Re: [PHP-DEV] Re: OpenSSL ext. improvements for authenticated cipher modes.

On Sun, Feb 1, 2015 at 1:07 PM, Jakub Zelenka bu...@php.net wrote: Hey, On Sun, Feb 1, 2015 at 5:49 PM, Daniel Lowrey rdlow...@php.net wrote: - openssl_decrypt() now returns mixed ... if $options['get_tag'] == true then return [$decryptedString, $tag], otherwise return $decrypted string

[PHP-DEV] Re: OpenSSL ext. improvements for authenticated cipher modes.

Hi list, A couple of bug reports have highlighted the fact that our openssl_encrypt and openssl_decrupt functions have no way of getting or setting tags required for authenticated cipher modes (i.e. GCM, CCM, OCB (not sure if this is available in OpenSSL)).

[PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

On Thu, Jan 29, 2015 at 8:14 PM, Michael Wallner m...@php.net wrote: I’ve rewritten the RFC for pecl_http and hopefully addressed most of the things mentioned previously. I you still find anything lacking, please let me know, so I can expand the RFC accordingly. And of course, everything

Re: [PHP-DEV] Re: Re: OpenSSL bug in 5.4.33 and 5.5.17

Hi! I'm typing on my phone at the airport so apologies for the brevity and lack of quoting from previous messages. I will summarize everything in detail with commit references to clear up any confusion in the next couple of days. I believe that by applying the patch below to the 5.4 and 5.5

Re: [PHP-DEV] Re: Re: OpenSSL bug in 5.4.33 and 5.5.17

On Wed, Sep 24, 2014 at 5:41 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Tue, Sep 23, 2014 at 4:41 PM, Julien Pauli jpa...@php.net wrote: On Tue, Sep 23, 2014 at 3:24 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Tue, Sep 23, 2014 at 7:39 AM, Daniel Lowrey rdlow...@gmail.com wrote

Re: [PHP-DEV] Re: Re: OpenSSL bug in 5.4.33 and 5.5.17

FYI: I've tagged 5.6.1 and I had to revert the following commits for this: 372844918a318ad712e16f9ec636682424a65403 f86b2193a483f56b0bd056570a0cdb57ebe66e2f 30a73658c63a91c413305a4c4d49882fda4dab3e 84a4041ba47e92e7a0ba03938d0ebf88b5fcf6cf 98e67add15a6b889efe152c23ed15a61f022a63a

[PHP-DEV] Re: PHP 5.6 and default cipher list in OpenSSL

Hi, Sorry to have not detect this problem at RFC time, but the new hardcoded cipher list, cause some trouble in Fedora. See: https://bugs.php.net/68074 http://fedoraproject.org/wiki/Changes/CryptoPolicy https://fedoraproject.org/wiki/User:Nmav/CryptoPolicies

[PHP-DEV] Re: Re: OpenSSL bug in 5.4.33 and 5.5.17

Hi, That's a bad thing we need to fix ASAP. I think for 5.6.1 we'll revert it , if not, we'll need an RC2, which is something we usually don't do (but as this could involve security, we may do it). The fix can be merged to 5.5.18RC1, next week, to have an RC cycle if not part of a

[PHP-DEV] Re: Re: OpenSSL bug in 5.4.33 and 5.5.17

Hi, That's a bad thing we need to fix ASAP. I think for 5.6.1 we'll revert it , if not, we'll need an RC2, which is something we usually don't do (but as this could involve security, we may do it). The fix can be merged to 5.5.18RC1, next week, to have an RC cycle if not part of a

[PHP-DEV] OpenSSL bug in 5.4.33 and 5.5.17

Hi folks! I know this isn't the kind of fun stuff people want to deal with on Friday but ... In an effort to fix a very old (seven years old) DoS vulnerability involving encrypted streams I created a regression where feof() notifications on encrypted sockets are broken. This is present in both

[PHP-DEV] Re: Re: HTTP supergloblas and request body/query (was: Parsing PUT data)

You can't efficiently model an HTTP request with associative arrays. Period. The fact is that for 99% of use cases, yes you can, and developers happily do so. Leaky abstraction is leaky. If this is truly an efficient model of the HTTP request then why do we fragment it out into $_SERVER and

[PHP-DEV] Re: HTTP supergloblas and request body/query (was: Parsing PUT data)

Uhmmm... I actually meant an interal API not userland :) Hehe, I'd be really excited to see this in userland too. Happy to help make this happen unless people have good reasons not to expose the parsers ...

[PHP-DEV] Re: HTTP supergloblas and request body/query (was: Parsing PUT data)

The superglobals are a hopelessly poor abstraction. Can we stop trying to put the proverbial gold ring in the pig's snout on this? While a change to `$_QUERY` and `$_BODY` would undoubtedly be an improvement I don't think the massive BC breaks that would result are justified by simply improving

[PHP-DEV] Wiki karma, por favor.

Good day, security-conscious internals people. I'm ready to float an RFC + patch for default SSL/TLS peer verification and TLSv1.1/TLSv1.2 support as mentioned in this thread: http://news.php.net/php.internals/69375 If someone would be kind enough to grant me the requisite wiki karma (user:

Re: [PHP-DEV] Re: Re: PHP Crypt functions - security audit

, Daniel Lowrey rdlow...@gmail.com wrote: Hello security-conscious internals people! I've got (what believe to be) a pretty good working solution for the problem of insecure-by-default stream encryption. I need to do some more thorough testing before pushing it upstream to a public fork but here's

[PHP-DEV] Re: Parsing PUT data

In short, in order to provide a proper REST service that supports multipart form data, we need someway to parse data sent via PUT (data is available via php://input, but it needs to be parsed). Multipart entity parsing is fairly straightforward. You could easily write a parser in userland to

[PHP-DEV] Re: Parsing PUT data

encountered when writing a public REST API in PHP. Dave. On 24/09/2013, at 7:59, Daniel Lowrey rdlow...@gmail.com wrote: In short, in order to provide a proper REST service that supports multipart form data, we need someway to parse data sent via PUT (data is available via php://input

[PHP-DEV] Re: Parsing PUT data

I am not the tone police, but I don't think such comments are helpful. Hey, sorry all :) Not trying to suggest anyone is incapable of writing working code (I know I am from time to time). I was simply ticking off my objections to the arguments presented. I'm in favor of kinder, gentler internals

Re: [PHP-DEV] Re: Re: PHP Crypt functions - security audit

Hello security-conscious internals people! I've got (what believe to be) a pretty good working solution for the problem of insecure-by-default stream encryption. I need to do some more thorough testing before pushing it upstream to a public fork but here's the quick and dirty: --- Summary --- -

[PHP-DEV] Re: Re: PHP Crypt functions - security audit

, 2013, Nikita Popov wrote: On Sat, Sep 21, 2013 at 10:18 PM, Daniel Lowrey rdlow...@gmail.comjavascript:_e({}, 'cvml', 'rdlow...@gmail.com'); wrote: Hello security-conscious internals people! I've got (what believe to be) a pretty good working solution for the problem of insecure

Re: [PHP-DEV] Re: Re: PHP Crypt functions - security audit

19, 2013 at 2:23 AM, Ryan McCue li...@rotorised.com wrote: Daniel Lowrey wrote: This is incorrect. PHP has supported both the SNI_enabled and SNI_server_name SSL context options since 5.3. Anything older than 5.3 is not remotely worth worrying over. You can verify this for yourself using

Re: [PHP-DEV] Re: Re: PHP Crypt functions - security audit

If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification

Re: [PHP-DEV] Re: Re: PHP Crypt functions - security audit

I think we should do this in 5.6. +1 ... a renewed emphasis on security makes a good selling point when answering the why should I upgrade questions. At the same time, targeting the next minor version gives people ample time to plan/test/document changes. Secure stream encryption settings by

Re: [PHP-DEV] Re: Re: PHP Crypt functions - security audit

stream context option (and subsidized my laziness) :) On Wed, Sep 18, 2013 at 9:06 PM, Tjerk Anne Meesters datib...@php.netwrote: On Thu, Sep 19, 2013 at 8:33 AM, Ángel González keis...@gmail.com wrote: On 16/09/13 15:58, Daniel Lowrey wrote: More generally, PHP's stream encryption

[PHP-DEV] Re: Re: PHP Crypt functions - security audit

PHP itself doesn't do much crypto stuff. We rely mostly on libs like openssl etc. and provide hashing algorithms which follow the specifications. If the specifications are bad this is a global non-PHP issue. That's all true, of course. But there are still places where new patches to the

Re: [PHP-DEV] Re: New function: stream_socket_listen()

trying to set arbitrary options on a socket before binding. That said, I'm have no actual objection to Daniel's patch, and I too would like to see a stream_socket_set_option() or similar. My $0.02 Thanks, Chris -Original Message- From: Daniel Lowrey [mailto:rdlow...@gmail.com

Re: [PHP-DEV] Re: New function: stream_socket_listen()

at deprecating fsockopen()/pfsockopen()? These genuinely are just old, less flexible duplications of stream_socket_client(), which is enabled by default. Cheers, Chris On 6 September 2013 14:03, Daniel Lowrey rdlow...@gmail.com wrote: This is a reasonable point. Personally I'd prefer to have

[PHP-DEV] New function: stream_socket_listen()

The stream socket functions are incredibly useful and obviate the need for the sockets extension for the vast majority of potential use-cases. However, it's currently it's not possible bind a socket and listen for connections in separate steps using stream_socket_server(). This _can_ be done with

[PHP-DEV] Re: New function: stream_socket_listen()

a conversation with him when he first implemented stream_socket_*() and a reason why listen wasn't in the API. -Sara On Thu, Sep 5, 2013 at 10:30 AM, Daniel Lowrey rdlow...@gmail.comjavascript:_e({}, 'cvml', 'rdlow...@gmail.com'); wrote: The stream socket functions are incredibly useful

[PHP-DEV] .phpt test question

I've been doing a good deal of socket work lately and have some minor stream socket server additions to float, but before I do so I need to add some tests. None of the standard stream socket functionality currently has any tests (stream_socket_pair() being the exception), so there's not much to

[PHP-DEV] Re: .phpt test question

On further consideration this is probably better addressed by setting the relevant socket streams to non-blocking so that a client connection can be created in the same process space and tested utilizing select() and an event loop. This would obviate the need for a proc_open() altogether. Thanks

[PHP-DEV] Language constructs and callability

I have a simple question about the callability of language constructs and whether or not that's something that might change in the future. Consider: var_dump(is_callable('echo')); // bool(false) var_dump(call_user_func('echo', 'foo')); // E_WARNING echo('foo'); // foo

Re: [PHP-DEV] Language constructs and callability

2013 17:36, Daniel Lowrey rdlow...@gmail.com wrote: I have a simple question about the callability of language constructs and whether or not that's something that might change in the future. Consider: var_dump(is_callable('echo')); // bool(false) var_dump(call_user_func('echo', 'foo

Re: [PHP-DEV] Language constructs and callability

Peter Cowburn petercowb...@gmail.com On 19 July 2013 17:36, Daniel Lowrey rdlow...@gmail.com wrote: I have a simple question about the callability of language constructs and whether or not that's something that might change in the future. Consider: var_dump(is_callable('echo')); // bool

Re: [PHP-DEV] Language constructs and callability

to counterbalance any benefits. Then again, who needs readability/maintainability when you can write hopelessly impenetrable code? :) On Fri, Jul 19, 2013 at 1:23 PM, Arpad Ray array...@gmail.com wrote: On Fri, Jul 19, 2013 at 5:36 PM, Daniel Lowrey rdlow...@gmail.com wrote: How deeply ingrained

[PHP-DEV] Re: Access-Control-Allow-Origin header in CLI server

This is not the sort of thing that belongs in an HTTP server by default. It's a one-off header that some users may elect to send but the vast majority will not. If you need to simulate the feature of an third-party server mod/plugin you should manually make a `header('Access-Control-Allow-Origin:

[PHP-DEV] Re: Gauging Interest:RFC to add map() function

Aside from the previously expressed reservations to the name map(), is anyone actually comfortable with *five* required arguments? That's serious cognitive overload; a more concise API is needed. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

[PHP-DEV] Re: date.timezone E_WARNING -- Really necessary? What's the rationale?

Having started this thread I'd like to focus the discussion so we can actually get somewhere. Otherwise opinions will keep streaming in ad nauseum without any real progress. At issue here is not whether UTC makes sense as a default. The question is also not how we can automate the install process

[PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

timezones work. I appreciate Derrick's work on the extension but I have yet to see any valid justification for triggering an error when no error actually exists. On Monday, May 27, 2013, Pierre Joye wrote: On Tue, May 28, 2013 at 12:57 AM, Daniel Lowrey rdlow...@gmail.com wrote: My problem

Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

never learn to fly. I get that everyone doesn't agree, but this seems like a no-brainer to me. On Fri, May 24, 2013 at 5:35 PM, Nikita Popov nikita@gmail.com wrote: On Fri, May 24, 2013 at 2:40 AM, Derick Rethans der...@php.net wrote: On Thu, 23 May 2013, Daniel Lowrey wrote: I guess my

[PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

I'm probably not the typical PHP user; I spend 99% of my PHP time using the CLI (and not web SAPIs). This means that I frequently run PHP without an .ini file. As a result, when I use any of the date/time functionality I invariably end up with this awesomeness: Warning: date(): It is not safe to

Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

I guess my point is that I don't believe default settings should trigger errors. If it's a default setting, it's a default setting. Document it and move on. It's then the user's responsibility to define that value correctly if he/she wants something other than the default. I don't personally see