Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

Dmitry, > but it's possible to get the same power translating string values of attributes into AST in the hooks. Aware. Enough of the complexity is already the responsibility of the consumer of the attributes. It's already possible to get strings (and so AST) from doc comments, we don't need an

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Hi Pierre, On Wed, May 11, 2016 at 2:19 PM, Pierre Joye wrote: > On May 11, 2016 11:46 AM, "Yasuo Ohgaki" wrote: > >> Thank you for your comments. I've updated the RFC. You might like this >> version. >> > > I still think we should not have that in core. If we do, it should be > controlled by th

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

On 05/11/2016 09:02 AM, Joe Watkins wrote: Morning Dmitry, > On the other hand simple string may be parsed into AST with just one additional call to ast\compile_string(). You're not really suggesting that I write my tools in user land, are you ? It's me, Joe :)ce At first days of RFC dis

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

2016-05-11 6:50 GMT+02:00 Yasuo Ohgaki : > Hi Niklas, > > On Wed, May 11, 2016 at 1:40 PM, Niklas Keller wrote: > > Yasuo Ohgaki schrieb am Mi., 11. Mai 2016 00:05: > >> > >> Hi Stas, > >> > >> On Wed, May 11, 2016 at 12:32 AM, Stanislav Malyshev > >> wrote: > >> >> What happens with applicatio

AW: [PHP-DEV] [RFC] Allow loading extensions by name

> -Ursprüngliche Nachricht- > Von: François Laupretre [mailto:franc...@php.net], Gesendet: Dienstag, 10. > Mai 2016 15:23 > > Please read and comment : > > https://wiki.php.net/rfc/load-ext-by-name > > Regards > > François > Why not just naming them *.so on all platforms and removing the

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

Morning, Because you have confused the vote by adding additional options very late in the discussion, and because the majority are in favour of something I think is harmful; I've had to vote no, on a feature that I want :s Cheers Joe On Wed, May 11, 2016 at 7:02 AM, Joe Watkins wrote: > Mo

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

Morning Dmitry, > On the other hand simple string may be parsed into AST with just one additional call to ast\compile_string(). You're not really suggesting that I write my tools in user land, are you ? It's me, Joe :) I *only* want attributes as they were originally proposed, and I can't vote t

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

Hi Joe, The sense in native support for AST is questionable. On one hand this allows syntax verification. On the other hand simple string may be parsed into AST with just one additional call to ast\compile_string(). Thanks. Dmitry. From: Joe Watkins Sent

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Hi Pierre, On Wed, May 11, 2016 at 1:12 PM, Pierre Joye wrote: > The current session code and designs is old, very old. It does not match > today ways to do things. Every time we fix it, I see a band aid fix. Let's rewrite session module someday. In the meantime, I would like to add features to

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

On May 11, 2016 11:46 AM, "Yasuo Ohgaki" wrote: > Thank you for your comments. I've updated the RFC. You might like this version. > I still think we should not have that in core. If we do, it should be controlled by the application implementation and not ini settings (some routes may have it, ot

Re: [PHP-DEV] [RFC] Allow loading extensions by name

Morning, > In this case, it is currently impossible to write a single configuration file that will work in both environments, forcing developers to manually maintain two separate versions of the file. I'm aware this has been mentioned in this thread, and I've read the open issue disclaimer. The

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Hi Niklas, On Wed, May 11, 2016 at 1:40 PM, Niklas Keller wrote: > Yasuo Ohgaki schrieb am Mi., 11. Mai 2016 00:05: >> >> Hi Stas, >> >> On Wed, May 11, 2016 at 12:32 AM, Stanislav Malyshev >> wrote: >> >> What happens with applications that do not produce HTML at all, such as >> >> REST, >> >>

Re: [PHP-DEV] run-tests.php improvement for PHP 7.0+

Morning, I would prefer adding a zend extensions section, there might not be that many in zend extensions in the wild, but there are behind closed doors. Cheers Joe On Tue, May 10, 2016 at 7:13 AM, Benjamin Eberlei wrote: > On Tue, May 10, 2016 at 6:36 AM, Matt Ficken > wrote: > > > An IN

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

On Wed, May 11, 2016 at 1:12 PM, Pierre Joye wrote: > On May 10, 2016 10:25 AM, "Yasuo Ohgaki" wrote: >> >> Hi all, >> >> It's not nice to work on the same code (i.e. session module) for >> multiple RFCs, but time is limited. >> >> I would like to hear from ideas/comments before I write patch for

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

Morning Dmitry, I'm not really happy with the voting options here. I would not vote in favour of a patch that does not include support for AST, that's a completely different feature. As it is, I have to vote yes in favour of AST, but it may be counted as a vote in favour of attribute

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Yasuo Ohgaki schrieb am Mi., 11. Mai 2016 00:05: > Hi Stas, > > On Wed, May 11, 2016 at 12:32 AM, Stanislav Malyshev > wrote: > >> What happens with applications that do not produce HTML at all, such as > REST, > >> - These apps may add SESSCSRF value manually. > > > > Add where? And where that

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Hi Kinn, On Wed, May 11, 2016 at 11:56 AM, Kinn Julião wrote: > The point with your example is: > The cross site can request the "get_csrf_token.php", store on its session > (even curl can save the session id cookie or whatever), get the token and > request the endpoint with the retrieved token a

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Yasuo Ohgaki schrieb am Mi., 11. Mai 2016 03:11: > Hi Stas, > > On Wed, May 11, 2016 at 7:58 AM, Stanislav Malyshev > wrote: > >>> Add where? And where that value would come from? RFC says nothing about > >>> that. > >> > >> As usual. Query parameter when GET is used. Additional input when POST

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Hi, On May 10, 2016 10:25 AM, "Yasuo Ohgaki" wrote: > > Hi all, > > It's not nice to work on the same code (i.e. session module) for > multiple RFCs, but time is limited. > > I would like to hear from ideas/comments before I write patch for this. > https://wiki.php.net/rfc/automatic_csrf_protecti

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

The point with your example is: The cross site can request the "get_csrf_token.php", store on its session (even curl can save the session id cookie or whatever), get the token and request the endpoint with the retrieved token and session id. Got it? On May 10, 2016 10:53 PM, "Kinn Julião" wrote:

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

You seemed to misunderstood your own "get_csrf_token.php" and how attackers would benefit from that. Anyway, you're trying to transfer an application behaviour to the core... Stick to -1. On May 10, 2016 10:18 PM, "Yasuo Ohgaki" wrote: > Hi Kinn, > > On Wed, May 11, 2016 at 10:20 AM, Kinn Julião

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Hi Kinn, On Wed, May 11, 2016 at 10:20 AM, Kinn Julião wrote: >> JS code that does not have pages at all may obtain CSRF token manually. > > That's against CSRF protection... in fact, a remote app can obtain the token > also and make the cross site request forgery... > > -1 You seem to __misunde

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

> JS code that does not have pages at all may obtain CSRF token manually. That's against CSRF protection... in fact, a remote app can obtain the token also and make the cross site request forgery... -1 On Tue, May 10, 2016 at 9:17 PM, Yasuo Ohgaki wrote: > Hi Stas, > > On Wed, May 11, 2016 at

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Hi Stas, On Wed, May 11, 2016 at 7:58 AM, Stanislav Malyshev wrote: >>> Add where? And where that value would come from? RFC says nothing about >>> that. >> >> As usual. Query parameter when GET is used. Additional input when POST >> is used. All users have to do is adding CSRF token to JS progra

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Hi Stas, On Wed, May 11, 2016 at 7:58 AM, Stanislav Malyshev wrote: >>> Add where? And where that value would come from? RFC says nothing about >>> that. >> >> As usual. Query parameter when GET is used. Additional input when POST >> is used. All users have to do is adding CSRF token to JS progra

[PHP-DEV] Re: [RFC DRAFT] Automatic CSRF Protection

Hi All, On Tue, May 10, 2016 at 12:24 PM, Yasuo Ohgaki wrote: > It's not nice to work on the same code (i.e. session module) for > multiple RFCs, but time is limited. > > I would like to hear from ideas/comments before I write patch for this. > https://wiki.php.net/rfc/automatic_csrf_protection >

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Hi, On Wed, May 11, 2016 at 7:06 AM, Yasuo Ohgaki wrote: > On Wed, May 11, 2016 at 1:48 AM, Fleshgrinder wrote: >> On 5/10/2016 5:24 AM, Yasuo Ohgaki wrote: >>> Hi all, >>> >>> It's not nice to work on the same code (i.e. session module) for >>> multiple RFCs, but time is limited. >>> >>> I woul

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Hi! > Did you read RFC? > It does not enable CSRF protection for all website, but only when it is > enabled. The RFC says: "Default: session.csrf_protection=1". Which means all sites would have it (for POST) unless they specifically disable it by changing configuration. Also, new variants do no

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Hi! >> Add where? And where that value would come from? RFC says nothing about >> that. > > As usual. Query parameter when GET is used. Additional input when POST > is used. All users have to do is adding CSRF token to JS program. GET and POST aren't the only HTTP methods. And where JS program w

Re: [PHP-DEV] [RFC] Allow loading extensions by name

Hi, Le 10/05/2016 à 22:07, Lester Caine a écrit : Windows did not worry about which extension was used in the past, but nowadays the problem is ensuring the correct build of extension is accessed and while 32bit is still the safer base, it's all too easy to get them mixed up with 64bit builds.

Re: [PHP-DEV] [RFC] Allow loading extensions by name

Hi Lester, Le 10/05/2016 à 21:01, Lester Caine a écrit : The idea has been proposed before, but the addition of php_ for windows installs has not been universally applied. Extensions like eAccelerator, adodb and other third party extensions that did not form part of the windows 'installation' f

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

Den 2016-05-11 kl. 00:00, skrev Dmitry Stogov: On 05/11/2016 12:29 AM, Björn Larsson wrote: Den 2016-05-10 kl. 20:29, skrev Dmitry Stogov: Hi internals, I've started voting on "PHP Attributes" RFC. https://wiki.php.net/rfc/attributes In my opinion, "PHP Attributes" might be a smart too

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Hi, On Wed, May 11, 2016 at 1:48 AM, Fleshgrinder wrote: > On 5/10/2016 5:24 AM, Yasuo Ohgaki wrote: >> Hi all, >> >> It's not nice to work on the same code (i.e. session module) for >> multiple RFCs, but time is limited. >> >> I would like to hear from ideas/comments before I write patch for thi

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Hi Stas, On Wed, May 11, 2016 at 12:32 AM, Stanislav Malyshev wrote: >> What happens with applications that do not produce HTML at all, such as REST, >> - These apps may add SESSCSRF value manually. > > Add where? And where that value would come from? RFC says nothing about > that. As usual. Qu

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Hi Rowan, On Tue, May 10, 2016 at 9:36 PM, Rowan Collins wrote: > Yasuo Ohgaki wrote on 10/05/2016 11:57: >> >> To protect all of URLs automatically, all URLs need to have token. >> That's the reason why all URLs have token. > > > In my opinion, that fails on both counts: not all URLs need protec

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

On 05/11/2016 12:29 AM, Björn Larsson wrote: Den 2016-05-10 kl. 20:29, skrev Dmitry Stogov: Hi internals, I've started voting on "PHP Attributes" RFC. https://wiki.php.net/rfc/attributes In my opinion, "PHP Attributes" might be a smart tool for PHP extension, but it's not going to be t

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

Den 2016-05-10 kl. 20:29, skrev Dmitry Stogov: Hi internals, I've started voting on "PHP Attributes" RFC. https://wiki.php.net/rfc/attributes In my opinion, "PHP Attributes" might be a smart tool for PHP extension, but it's not going to be the end of the world, if we decided to live with

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

On 05/10/2016 11:48 PM, Benjamin Eberlei wrote: On Tue, May 10, 2016 at 8:29 PM, Dmitry Stogov > wrote: Hi internals, I've started voting on "PHP Attributes" RFC. https://wiki.php.net/rfc/attributes In my opinion, "PHP Attributes" might be a sma

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

On Tue, May 10, 2016 at 8:29 PM, Dmitry Stogov wrote: > Hi internals, > > > I've started voting on "PHP Attributes" RFC. > > > https://wiki.php.net/rfc/attributes > > > In my opinion, "PHP Attributes" might be a smart tool for PHP extension, > but it's not going to be the end of the world, if we

Re: [PHP-DEV] Re: [RFC][VOTE] Nullable Types

On Tue, May 10, 2016 at 1:13 PM, Lester Caine wrote: > On 10/05/16 17:27, Levi Morrison wrote: >> Voting will close on Friday, May 20th, 2016 sometime in the evening of UTC-6. > > Quick question ... if I simply strip this extra '?' if some library has > added it will it actually make any differenc

Re: [PHP-DEV] [RFC] Allow loading extensions by name

On 10/05/16 20:18, Fleshgrinder wrote: > WIN: `php -d extension=php_foo.dll -d zend_extension=php_bar.dll` I would be most surprised to find windows users running php command line, but I suppose I am somewhat out of the loop on that side. All my windows users run PHP on a web server and have troub

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

A couple of quick comments - I'm sorry, I haven't had time to get them in before now. In my opinion, this is pretty bad, for one primary reason: these are just names and values. The advantage of this over parsing doc-blocks at run-time is pretty limited - you can basically only guarantee syntax,

Re: [PHP-DEV] [RFC] Allow loading extensions by name

On 5/10/2016 9:01 PM, Lester Caine wrote: > The idea has been proposed before, but the addition of php_ for windows > installs has not been universally applied. Extensions like eAccelerator, > adodb and other third party extensions that did not form part of the > windows 'installation' files. Most

Re: [PHP-DEV] Re: [RFC][VOTE] Nullable Types

On 10/05/16 17:27, Levi Morrison wrote: > Voting will close on Friday, May 20th, 2016 sometime in the evening of UTC-6. Quick question ... if I simply strip this extra '?' if some library has added it will it actually make any difference to the results? I still think the whole concept of 'null' ne

Re: [PHP-DEV] [RFC] Allow loading extensions by name

On 10/05/16 17:27, Fleshgrinder wrote: >> Please read and comment : >> > >> > https://wiki.php.net/rfc/load-ext-by-name >> > > +1 and I am wondering why nobody else ever came to this idea. The idea has been proposed before, but the addition of php_ for windows installs has not been universally a

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

On 5/10/2016 8:29 PM, Dmitry Stogov wrote: > Hi internals, > > I've started voting on "PHP Attributes" RFC. > > https://wiki.php.net/rfc/attributes > > In my opinion, "PHP Attributes" might be a smart tool for PHP extension, but > it's not going to be the end of the world, if we decided to live

[PHP-DEV] [RFC] [VOTE] PHP Attributes

Hi internals, I've started voting on "PHP Attributes" RFC. https://wiki.php.net/rfc/attributes In my opinion, "PHP Attributes" might be a smart tool for PHP extension, but it's not going to be the end of the world, if we decided to live with doc-comments only. Thanks. Dmitry.

Re: [PHP-DEV] [RFC] Allow loading extensions by name

On 10/05/2016 17:54, Stanislav Malyshev wrote: Hi! Please read and comment : https://wiki.php.net/rfc/load-ext-by-name The RFC says " it is currently impossible to write a single configuration file that will work in both environments" - but even with extension fix, wouldn't it be still impos

Re: [PHP-DEV] [RFC] Allow loading extensions by name

Hi, Le 10/05/2016 à 18:54, Stanislav Malyshev a écrit : The RFC says " it is currently impossible to write a single configuration file that will work in both environments" - but even with extension fix, wouldn't it be still impossible since Windows are Unix paths would probably be different? Y

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

On 10 May 2016 at 17:48, Fleshgrinder wrote: > On 5/10/2016 5:24 AM, Yasuo Ohgaki wrote: > > Hi all, > > > > It's not nice to work on the same code (i.e. session module) for > > multiple RFCs, but time is limited. > > > > I would like to hear from ideas/comments before I write patch for this. > >

Re: [PHP-DEV] [RFC] Allow loading extensions by name

On 5/10/2016 6:56 PM, Fleshgrinder wrote: > On 5/10/2016 6:54 PM, Stanislav Malyshev wrote: >> Hi! >> Please read and comment : https://wiki.php.net/rfc/load-ext-by-name >> >> The RFC says " it is currently impossible to write a single >> configuration file that will work in both env

Re: [PHP-DEV] [RFC] Allow loading extensions by name

On 5/10/2016 6:54 PM, Stanislav Malyshev wrote: > Hi! > >>> Please read and comment : >>> >>> https://wiki.php.net/rfc/load-ext-by-name > > The RFC says " it is currently impossible to write a single > configuration file that will work in both environments" - but even with > extension fix, wouldn

Re: [PHP-DEV] [RFC] Allow loading extensions by name

Hi! >> Please read and comment : >> >> https://wiki.php.net/rfc/load-ext-by-name The RFC says " it is currently impossible to write a single configuration file that will work in both environments" - but even with extension fix, wouldn't it be still impossible since Windows are Unix paths would pr

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

On 5/10/2016 5:24 AM, Yasuo Ohgaki wrote: > Hi all, > > It's not nice to work on the same code (i.e. session module) for > multiple RFCs, but time is limited. > > I would like to hear from ideas/comments before I write patch for this. > https://wiki.php.net/rfc/automatic_csrf_protection > > Than

[PHP-DEV] Re: [RFC][VOTE] Nullable Types

On Tue, May 10, 2016 at 9:22 AM, Levi Morrison wrote: > Dmitry and I have opened [voting on Nullable Types][1]. Note that I > have changed the phrasing of the two votes but the structure and > outcomes are the same. Hopefully these changes help clarify the > possible results. > > I thank everyone

Re: [PHP-DEV] [RFC] Allow loading extensions by name

On 5/10/2016 3:22 PM, François Laupretre wrote: > Please read and comment : > > https://wiki.php.net/rfc/load-ext-by-name > +1 and I am wondering why nobody else ever came to this idea. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Hi! > What happens with applications that do not produce HTML at all, such as REST, > - These apps may add SESSCSRF value manually. Add where? And where that value would come from? RFC says nothing about that. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Ma

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Hi! > To protect all of URLs automatically, all URLs need to have token. > That's the reason why all URLs have token. The risk is the same as > Trans SID session management. But not all URLs need protecting. There are a lot of URLs that do not need protecting - and there are a lot of actions, esp

[PHP-DEV] [RFC][VOTE] Nullable Types

Dmitry and I have opened [voting on Nullable Types][1]. Note that I have changed the phrasing of the two votes but the structure and outcomes are the same. Hopefully these changes help clarify the possible results. I thank everyone who has contributed to the implementation or discussion for their

[PHP-DEV] BAD Benchmark Results for PHP Master 2016-05-10

Results for project PHP master, build date 2016-05-10 06:29:58+03:00 commit: f9bead7 previous commit:7b65346 revision date: 2016-05-09 18:52:21+02:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB

[PHP-DEV] [RFC] Allow loading extensions by name

Please read and comment : https://wiki.php.net/rfc/load-ext-by-name Regards François --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe,

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Yasuo Ohgaki wrote on 10/05/2016 11:57: To protect all of URLs automatically, all URLs need to have token. That's the reason why all URLs have token. In my opinion, that fails on both counts: not all URLs need protection (I would say for most applications, the majority of URLs do not need it)

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Why use sessions for CSRF Protection? That an be implemented with simple cookies. https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet#Double_Submit_Cookies Btw, not sure if this should be in php core though...it's more an application thing... On Tue, May

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Yasuo Ohgaki schrieb am Di., 10. Mai 2016 12:57: > Hi Rowan, > > On Tue, May 10, 2016 at 6:38 PM, Rowan Collins > wrote: > > Yasuo Ohgaki wrote on 10/05/2016 04:24: > >> > >> Hi all, > >> > >> It's not nice to work on the same code (i.e. session module) for > >> multiple RFCs, but time is limite

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Hi Stas, On Tue, May 10, 2016 at 1:44 PM, Stanislav Malyshev wrote: >> I would like to hear from ideas/comments before I write patch for this. >> https://wiki.php.net/rfc/automatic_csrf_protection > > Could you explain a bit more - when token validation happens? Where the > SESSCSRF comes from? D

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Hi Rowan, On Tue, May 10, 2016 at 6:38 PM, Rowan Collins wrote: > Yasuo Ohgaki wrote on 10/05/2016 04:24: >> >> Hi all, >> >> It's not nice to work on the same code (i.e. session module) for >> multiple RFCs, but time is limited. >> >> I would like to hear from ideas/comments before I write patch

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Yasuo Ohgaki wrote on 10/05/2016 04:24: Hi all, It's not nice to work on the same code (i.e. session module) for multiple RFCs, but time is limited. I would like to hear from ideas/comments before I write patch for this. https://wiki.php.net/rfc/automatic_csrf_protection I think rewriting eve