> 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:
> http://www.php.net/unsub.php
> 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.
>
On Tue, Mar 31, 2015 at 10:11 AM Grégory Planchat 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
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
detail
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
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 coming
On Sun, Mar 15, 2015 at 4:39 PM, Damien Tournoud wrote:
>
> On Sun, Mar 15, 2015 at 9:35 PM, Daniel Lowrey wrote:
>>
>> This is actually a *vastly* inferior solution to language-level support
for generator returns. greenlet/gevent does it this way because these
libraries w
On Sun, Mar 15, 2015 at 4:13 PM, Damien Tournoud 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 allow
On Sun, Mar 15, 2015 at 3:56 PM, Damien Tournoud 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 ...
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
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 *
to
yield from
I encourage all interested parties to
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.
I
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 separat
>From initial discussions it seems prudent to modify the Generator
Delegation RFC to use either of:
- yield from
- yield use
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 like t
On Mon, Mar 2, 2015 at 1:34 AM, Patrick Schaaf wrote:
>
> Am 02.03.2015 00:52 schrieb "Daniel Lowrey" :
> >
> > I'd like to initiate discussion on a proposal to implement generator
> > delegation via the following new syntax inside generator functions:
>
Hi folks,
I'd like to initiate discussion on a proposal to implement generator
delegation via the following new syntax inside generator functions:
yield *
The Generator Delegation RFC is available here:
https://wiki.php.net/rfc/generator-delegation
This proposal is conceptually related to
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:
https://wiki.php.net/rfc/generator-
On Mon, Feb 16, 2015 at 11:00 AM, Arvids Godjuks
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 each other's point of
view
On Mon, Feb 16, 2015 at 10:19 AM, Zeev Suraski 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
> 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 providi
On Wed, Feb 11, 2015 at 5:16 PM, Michael Wallner 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
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
-
On Sun, Feb 8, 2015 at 2:18 PM, Tom Worster wrote:
>
> On 2/8/15, 12:52 PM, "Daniel Lowrey" wrote:
>
> >On Sun, Feb 8, 2015 at 12:11 PM, Tom Worster wrote:
> >>
> >> Thanks Damien and Daniel for the info.
> >>
> >> I am not
On Sun, Feb 8, 2015 at 12:11 PM, Tom Worster 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 clear (as Da
On Sun, Feb 8, 2015 at 4:24 AM, Tom Worster 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 extension in pe
>> 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 b
> 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
On Sun, Feb 1, 2015 at 1:07 PM, Jakub Zelenka wrote:
> Hey,
>
> On Sun, Feb 1, 2015 at 5:49 PM, Daniel Lowrey wrote:
>>
>> - openssl_decrypt() now returns mixed ... if $options['get_tag'] == true
>> then return [$decryptedString, $tag], otherwise return
> 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)).
>
> https://bugs.php.net/bug.
On Thu, Jan 29, 2015 at 8:14 PM, Michael Wallner 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 else is
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 branch
> FYI: I've tagged 5.6.1 and I had to revert the following commits for this:
> 372844918a318ad712e16f9ec636682424a65403
> f86b2193a483f56b0bd056570a0cdb57ebe66e2f
> 30a73658c63a91c413305a4c4d49882fda4dab3e
> 84a4041ba47e92e7a0ba03938d0ebf88b5fcf6cf
> 98e67add15a6b889efe152c23ed15a61f022a63a
>
> 98e
On Wed, Sep 24, 2014 at 5:41 AM, Ferenc Kovacs wrote:
>
>
>
> On Tue, Sep 23, 2014 at 4:41 PM, Julien Pauli wrote:
>>
>> On Tue, Sep 23, 2014 at 3:24 PM, Ferenc Kovacs wrote:
>> >
>> >
>> > On Tue, Sep 23, 2014 at 7:39 AM, Daniel Lowrey
wrote
>> 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
> 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
> 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
> https://wiki.php.net/r
>> 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 the most recent 5.4.33 and 5.5.17 releases.
> Can you please point us to the related
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 th
>> 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 an
> 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 ...
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 va
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:
rdlo
, Daniel Lowrey 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 bu
> 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" interna
.
>
> Other languages (Ruby, for example) make REST very easy. Multipart support
> for PUT was literally the only issue I personally encountered when writing
> a public REST API in PHP.
>
> Dave.
>
> On 24/09/2013, at 7:59, Daniel Lowrey wrote:
>
> > In short, in o
> 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
turday, September 21, 2013, Nikita Popov wrote:
>
> On Sat, Sep 21, 2013 at 10:18 PM, Daniel Lowrey
>
> > wrote:
>
>> Hello security-conscious internals people!
>>
>> I've got (what believe to be) a pretty good working solution for the
>> probl
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 ---
-
> 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
> 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
Thu, Sep 19, 2013 at 2:23 AM, Ryan McCue 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 wo
. Thank you to whomever updated
http://php.net/manual/en/context.ssl.phpto reflect the
"disable_compression" SSL stream context option (and
subsidized my laziness) :)
On Wed, Sep 18, 2013 at 9:06 PM, Tjerk Anne Meesters wrote:
>
>
>
> On Thu, Sep 19, 2013 at 8:33 AM, Ángel
> 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 un
t; requiring users to enable them manually.
>
> And if that were to happen, or even if not, could we look at deprecating
> fsockopen()/pfsockopen()? These genuinely are just old, less flexible
> duplications of stream_socket_client(), which is enabled by default.
>
> Cheers, Chris
ing more advanced - I saw
> multicast being banded about below - to the sockets extension. For
> instance,
> the
> API is likely to get messy if you start trying to set arbitrary options on
> a
> socket before binding.
>
> That said, I'm have no actual objection to Daniel&#
on
>
> > wrote:
>
>> Seems reasonable to me, but Wez should probably weigh in on it. I
>> vaguely recall a conversation with him when he first implemented
>> stream_socket_*() and a reason why listen wasn't in the API.
>>
>> -Sara
>>
>>
&
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
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 f
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 wor
ay be enough 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 wrote:
> On Fri, Jul 19, 2013 at 5:36 PM, Daniel Lowrey wrote:
>
>> How deeply ingrained into the engine
Peter Cowburn
>
>> On 19 July 2013 17:36, Daniel Lowrey 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:
>>
gt;
>
> On 19 July 2013 17:36, Daniel Lowrey 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
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
var_dump(is_callable('isset'
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: .
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: http://www.php.net/u
understand how 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
> wrote:
> >
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
inator? If
you don't kick the baby birds out of the nest they'll 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 wrote:
> On Fri, May 24, 2013 at 2:40 AM, Derick Rethans wrote:
>>
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 m
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
70 matches
Mail list logo
