Re: [PHP-DEV] [Discussion] Last chance for case-sensitive engine

On Tue, Feb 24, 2015 at 8:48 AM, Alexander Lisachenko wrote: > Morning! > > I want to ask this question one more time before PHP7 feature freeze: can > we the engine case sensitive from PHP>=7.0? > > There is a draft for that: https://wiki.php.net/rfc/case-sensitivity > (mostly empty), so I decid

Re: [PHP-DEV] Reclassify E_STRICT notices

On 24/02/15 07:20, Stanislav Malyshev wrote: >> I would like to propose reclassifying our few existing E_STRICT notices and >> > removing this error category: >> > >> > https://wiki.php.net/rfc/reclassify_e_strict > Could you add some more explanation about why it is a good thing? I.e., > E_S

Re: [PHP-DEV] [Discussion] Last chance for case-sensitive engine

On 24/02/15 08:02, Pavel Kouřil wrote: >> I want to ask this question one more time before PHP7 feature freeze: can >> > we the engine case sensitive from PHP>=7.0? >> > >> > There is a draft for that: https://wiki.php.net/rfc/case-sensitivity >> > (mostly empty), so I decided to ask this question

Re: [PHP-DEV] [Discussion] Last chance for case-sensitive engine

Hi Alexander, On Tue, Feb 24, 2015 at 4:48 PM, Alexander Lisachenko < lisachenko...@gmail.com> wrote: > There is a draft for that: https://wiki.php.net/rfc/case-sensitivity > (mostly empty), so I decided to ask this question in the internals mail > list. > > Pros: more simple O(1) hash table chec

Re: [PHP-DEV] [VOTE] Exceptions in the engine

Hi all, On Tue, Feb 24, 2015 at 4:28 PM, Pavel Kouřil wrote: > I personally find both BaseException and AbstractException ugly. The > "Throwable" is IMHO much better. > We definitely need coding(naming) standard :) We may have coding standard before PHP7 release and cleanup all. For people dis

Re: [PHP-DEV] [Discussion] Last chance for case-sensitive engine

On Tue, Feb 24, 2015 at 06:23:04PM +0900, Yasuo Ohgaki wrote: > INI switch is better. Compiler switch would not work well, since user cannot > check their code easily. > > PHP7 - introduce case sensitivity switch off by default > PHP8 - make case sensitivity switch on by default > PHP9 - remove c

Re: [PHP-DEV] [RFC] [DISCUSSION] Reliable user-land CSPRNG

Hi, On Tue, Feb 24, 2015 at 8:36 AM, Sammy Kaye Powers wrote: > The RFC to add a user-land API for an easy-to-use and reliable CSPRNG in > PHP is up for discussion: https://wiki.php.net/rfc/easy_userland_csprng > > This proposes adding two methods: `random_bytes()` and `random_int()` that > retur

[PHP-DEV] Re: [RFC] Script only include/require

Hi Dmitry, On Tue, Feb 24, 2015 at 4:00 PM, Dmitry Stogov wrote: > Use E_ERROR. > > >> >> >> https://github.com/php/php-src/pull//files#diff-93ad74868f98ff7232ebea7c8b7fR624 >> >> Does engine exception catches error from zend_error_noreturn()? >> > > no. it'll be changed into zend_error(

[PHP-DEV] Re: [RFC] Script only include/require

Hi all, On Tue, Feb 24, 2015 at 7:20 PM, Yasuo Ohgaki wrote: > On Tue, Feb 24, 2015 at 4:00 PM, Dmitry Stogov wrote: > >> Use E_ERROR. >> >> >>> >>> >>> https://github.com/php/php-src/pull//files#diff-93ad74868f98ff7232ebea7c8b7fR624 >>> >>> Does engine exception catches error from zend

Re: [PHP-DEV] [RFC] [DISCUSSION] Reliable user-land CSPRNG

It should use the session.entropy_file setting as it aims to be the exact same thing. It also allows custom entropy src (better ones for higher demands) as well. On Feb 23, 2015 10:36 PM, "Sammy Kaye Powers" wrote: > The RFC to add a user-land API for an easy-to-use and reliable CSPRNG in > PHP i

Re: [PHP-DEV] [RFC] [DISCUSSION] Reliable user-land CSPRNG

Hi Andrey, On 24 February 2015 at 09:51, Andrey Andreev wrote: > I noticed that the patch checks for /dev/arandom availability first, > and I'm pretty sure that on systems that have it, /dev/urandom simply > redirects to /dev/urandom, so that might be a bit redundant ... Maybe > Leigh can say mor

Re: [PHP-DEV] [VOTE] Exceptions in the engine

Hi, Am 23.02.2015 um 19:15 schrieb Nikita Popov: > A second vote will decide whether to use a BaseException based inheritance > hierarchy. This vote uses a simple majority. I like this RFC and hope it passes. I am a little concerned about littering the global namespace. It would be preferable to

Re: [PHP-DEV] [RFC] [DISCUSSION] Reliable user-land CSPRNG

On 24 February 2015 at 10:55, Pierre Joye wrote: > It should use the session.entropy_file setting as it aims to be the exact > same thing. It also allows custom entropy src (better ones for higher > demands) as well. I disagree. We want to take responsibility away from the user to choose the best

Re: [PHP-DEV] Coercive Scalar Type Hints RFC

Pierre Joye wrote on 24/02/2015 01:57: On Feb 23, 2015 2:48 PM, "Rowan Collins" > wrote: > > On 22 February 2015 23:56:18 GMT, Pierre Joye > wrote: > >Can you all of you stop this madness with moving discussions off list? > > > >It

[PHP-DEV] Re: Mark some functions with PREFER_REF

On Mon, Feb 23, 2015 at 10:36 PM, Nikita Popov wrote: > Hi internals! > > With regard to my E_STRICT RFC [1] Yasuo and another off-the-record mail > expressed a concern about the "Only variables should be passed by > reference" strict standards warning. > > This notices makes sense in a lot of pl

Re: [PHP-DEV] Re: [RFC] Script only include/require

Hi Dmitry, On 24 February 2015 at 07:00, Dmitry Stogov wrote: > I'm not a security expert, but I think that adding check for script > extension won't add significant level of protection. Will it add a significant level of protection? No. Does it add protection? Yes. Each time we add some incre

[PHP-DEV] Allow "tightening" of PHP_INI_SYSTEM directives in PHP_INI_PERDIR+ contexts?

Hi, Currently, some directives such as "expose_php" or "allow_url_fopen" can only be changed on the PHP_INI_SYSTEM level, which in some cases apparently even means through php.ini only. Wouldn't it make sense to allow "tightening" of these values in, say, a PERDIR contexts? So "expose_php" can

Re: [PHP-DEV] [VOTE] Exceptions in the engine

Hi all, On Tue, Feb 24, 2015 at 8:04 PM, Dennis Birkholz wrote: > Am 23.02.2015 um 19:15 schrieb Nikita Popov: > > A second vote will decide whether to use a BaseException based > inheritance > > hierarchy. This vote uses a simple majority. > > I like this RFC and hope it passes. I am a little c

Re: [PHP-DEV] [VOTE] Exceptions in the engine

2015-02-24 13:29 GMT+01:00 Yasuo Ohgaki : > Hi all, > > On Tue, Feb 24, 2015 at 8:04 PM, Dennis Birkholz > wrote: > > > Am 23.02.2015 um 19:15 schrieb Nikita Popov: > > > A second vote will decide whether to use a BaseException based > > inheritance > > > hierarchy. This vote uses a simple majori

Re: [PHP-DEV] The Game Theory of Scalar Type Hint Voting

On 23 February 2015 at 21:15, Albert Casademont Filella wrote: > I like it! That's what I proposed to Anthony (and Andrea before) before > Zeev presented their alternative, to held a double vote on the strict vs > weak feature. It was not met with much enthusiasm, hope they change their > minds wi

RE: [PHP-DEV] Coercive Scalar Type Hints RFC - BC breaks

I think I was not clear. *Every* 'break' I report here won't generate anything more than E_DEPRECATED in the final implementation. By definition. Ne need to wait for a better patch. François > -Message d'origine- > De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo >

[PHP-DEV] [RFC] Anonymous Classes

Good day! https://wiki.php.net/rfc/anonymous_classes There's a little RFC + patch that Joe Watkins put together, and as before with the ArrayOf RFC, I'll be helping out. So, lets get this discussion rolling. It was declined for PHP 5 some time ago, and has returned now to try for PHP 7. The us

Re: [PHP-DEV] Re: Mark some functions with PREFER_REF

On Tue, Feb 24, 2015 at 2:37 PM, Nikita Popov wrote: > On Mon, Feb 23, 2015 at 10:36 PM, Nikita Popov > wrote: > > > Hi internals! > > > > With regard to my E_STRICT RFC [1] Yasuo and another off-the-record mail > > expressed a concern about the "Only variables should be passed by > > reference"

Re: [PHP-DEV] [RFC] Anonymous Classes

I think the proposal is a bit incomplete. It's possible to instantiate an anonymous class, but currently it's not possible to do with them anything else (assign to variable, pass to function, etc). Something similar to Closure objects should be introduced. Thanks. Dmitry. On Tue, Feb 24, 2015 at

Re: [PHP-DEV] [RFC] Anonymous Classes

On Tue, Feb 24, 2015 at 9:10 AM, Dmitry Stogov wrote: > I think the proposal is a bit incomplete. > It's possible to instantiate an anonymous class, but currently it's not > possible to do with them anything else (assign to variable, pass to > function, etc). Something similar to Closure objects s

Re: [PHP-DEV] [RFC] Anonymous Classes

Hi Phil, Am 24.02.2015 um 14:52 schrieb Philip Sturgeon: > https://wiki.php.net/rfc/anonymous_classes I like the idea of having anonymous classes, it is very helpful during development to just try something out without having the burden of creating a new file and a complete class including namesp

Re: [PHP-DEV] [RFC] Anonymous Classes

On Tue, Feb 24, 2015 at 5:19 PM, Philip Sturgeon wrote: > On Tue, Feb 24, 2015 at 9:10 AM, Dmitry Stogov wrote: > > I think the proposal is a bit incomplete. > > It's possible to instantiate an anonymous class, but currently it's not > > possible to do with them anything else (assign to variable

Re: [PHP-DEV] [RFC] Anonymous Classes

On 02/24/2015 03:29 PM, Dennis Birkholz wrote: > Am 24.02.2015 um 14:52 schrieb Philip Sturgeon: >> https://wiki.php.net/rfc/anonymous_classes > > I like the idea of having anonymous classes, it is very helpful during > development to just try something out without having the burden of > creating

Re: [PHP-DEV] Reclassify E_STRICT notices

On Tue, Feb 24, 2015 at 8:20 AM, Stanislav Malyshev wrote: > Hi! > > > > > I would like to propose reclassifying our few existing E_STRICT notices > and > > removing this error category: > > > > https://wiki.php.net/rfc/reclassify_e_strict > > Could you add some more explanation about why it

Re: [PHP-DEV] Re: [RFC-Discuss] Scalar Type Declarations v0.5

I've been having a play around with the implementation, and it's been behaving pretty solidly, nothing unexpected so far. I've even gotten around my issue regarding no strict-by-default option for those of us who want it. Maybe this will sway a few voters. I'll put the source up if this particula

Re: [PHP-DEV] [RFC] Anonymous Classes

On Tue, Feb 24, 2015 at 9:58 AM, Florian Anderiasch wrote: > On 02/24/2015 03:29 PM, Dennis Birkholz wrote: >> Am 24.02.2015 um 14:52 schrieb Philip Sturgeon: >>> https://wiki.php.net/rfc/anonymous_classes >> >> I like the idea of having anonymous classes, it is very helpful during >> development

Re: [PHP-DEV] [RFC] Anonymous Classes

On Tue, Feb 24, 2015 at 9:34 AM, Dmitry Stogov wrote: > > > On Tue, Feb 24, 2015 at 5:19 PM, Philip Sturgeon > wrote: >> >> On Tue, Feb 24, 2015 at 9:10 AM, Dmitry Stogov wrote: >> > I think the proposal is a bit incomplete. >> > It's possible to instantiate an anonymous class, but currently it'

Re: [PHP-DEV] [RFC] Anonymous Classes

On 02/24/2015 04:31 PM, Philip Sturgeon wrote: > On Tue, Feb 24, 2015 at 9:58 AM, Florian Anderiasch > wrote: >> On 02/24/2015 03:29 PM, Dennis Birkholz wrote: >>> Am 24.02.2015 um 14:52 schrieb Philip Sturgeon: https://wiki.php.net/rfc/anonymous_classes >>> >>> I like the idea of having ano

[PHP-DEV] Feature request and RFC

Hi internals. I've made PR proposing a feature request: A new interface Sortable. https://github.com/php/php-src/pull/1116 If possible, I would like to create and RFC describing this in more detail, and perhaps get a voting on. Thanks Br, Thomas Gielfeldt

Re: [PHP-DEV] [RFC] Anonymous Classes

On Tue, Feb 24, 2015 at 7:52 AM, Philip Sturgeon wrote: > Good day! > > https://wiki.php.net/rfc/anonymous_classes > > There's a little RFC + patch that Joe Watkins put together, and as > before with the ArrayOf RFC, I'll be helping out. > > So, lets get this discussion rolling. > Anonymous classe

Re: [PHP-DEV] Feature request and RFC

Hi, On Tue, Feb 24, 2015 at 5:17 PM, Thomas Gielfeldt wrote: > Hi internals. > > I've made PR proposing a feature request: A new interface Sortable. > > https://github.com/php/php-src/pull/1116 > > If possible, I would like to create and RFC describing this in more detail, > and perhaps get a vo

Re: [PHP-DEV] [RFC] Anonymous Classes

On Tue, Feb 24, 2015 at 10:59 AM, Florian Anderiasch wrote: > On 02/24/2015 04:31 PM, Philip Sturgeon wrote: >> On Tue, Feb 24, 2015 at 9:58 AM, Florian Anderiasch >> wrote: >>> On 02/24/2015 03:29 PM, Dennis Birkholz wrote: Am 24.02.2015 um 14:52 schrieb Philip Sturgeon: > https://wiki

Re: [PHP-DEV] [RFC] Anonymous Classes

here is an example for opening a mysqli connection only when the first query is executed: $c = new class extends mysqli { public function query($query, $resultmode = MYSQLI_STORE_RESULT) { if (empty($this->host_info)) parent::real_connect('127.0.0.1', 'user', 'pwd', 'db'); return paren

Re: [PHP-DEV] [RFC] Anonymous Classes

On Tue, Feb 24, 2015 at 7:52 AM, Philip Sturgeon wrote: > Good day! > > https://wiki.php.net/rfc/anonymous_classes > > There's a little RFC + patch that Joe Watkins put together, and as > before with the ArrayOf RFC, I'll be helping out. > > So, lets get this discussion rolling. > > It was declin

Re: [PHP-DEV] [RFC] Anonymous Classes

On Tue, Feb 24, 2015 at 12:21 PM, Mike Willbanks wrote: > > > On Tue, Feb 24, 2015 at 7:52 AM, Philip Sturgeon > wrote: >> >> Good day! >> >> https://wiki.php.net/rfc/anonymous_classes >> >> There's a little RFC + patch that Joe Watkins put together, and as >> before with the ArrayOf RFC, I'll be

Re: [PHP-DEV] [RFC] Anonymous Classes

Would have been more useful, inline sintex like JSON: $object = { 'property': $value, 'method': function (){...} }; $object->property; $object->method(); -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Anonymous Classes

On Tue, Feb 24, 2015 at 1:37 PM, S.A.N wrote: > Would have been more useful, inline sintex like JSON: > > $object = > { > 'property': $value, > 'method': function (){...} > }; > > $object->property; > $object->method(); I know what you're saying here, and object literals like this would

Re: [PHP-DEV] [RFC] Anonymous Classes

2015-02-24 20:49 GMT+02:00 Philip Sturgeon : > On Tue, Feb 24, 2015 at 1:37 PM, S.A.N wrote: >> Would have been more useful, inline sintex like JSON: >> >> $object = >> { >> 'property': $value, >> 'method': function (){...} >> }; >> >> $object->property; >> $object->method(); > > I know w

Re: [PHP-DEV] [RFC] Anonymous Classes

I'm not sure if json syntax is better than PHP here: $object = (object)[ 'property'=>$value, 'method'=>function(){...} ]; $object->property; $object->method->__invoke(); S.A.N wrote on 24.02.2015 19:37: > Would have been more useful, inline sintex like JSON: > > $object = > { >'propert

Re: [PHP-DEV] Feature request and RFC

2015-02-24 17:36 GMT+01:00 Benjamin Eberlei : > Hi, > > On Tue, Feb 24, 2015 at 5:17 PM, Thomas Gielfeldt > wrote: > >> Hi internals. >> >> I've made PR proposing a feature request: A new interface Sortable. >> >> https://github.com/php/php-src/pull/1116 >> >> If possible, I would like to create

Re: [PHP-DEV] [RFC] Anonymous Classes

Hi! > https://wiki.php.net/rfc/anonymous_classes > > There's a little RFC + patch that Joe Watkins put together, and as > before with the ArrayOf RFC, I'll be helping out. > > So, lets get this discussion rolling. This is a nice and clear proposal, however I'm not sure I'm completely convinced

Re: [PHP-DEV] [RFC][VOTE] Improve array to string conversion

I think this is a huge bc break that will affect many applications. For example: // test.php error_reporting(E_ALL & ~E_NOTICE); echo $_GET['value']; curl http://.../test.php?value=foo // ok curl http://.../test.php?value[0]=foo&value[1]=bar // application continues with E_NOTICE curl http://...

Re: [PHP-DEV] [RFC] Anonymous Classes

Hi! > I like the idea of having anonymous classes, it is very helpful during > development to just try something out without having the burden of > creating a new file and a complete class including namespace and use > declarations, etc. I think this particular argument is a bit backwards. In PHP

Re: [PHP-DEV] [RFC][VOTE] Improve array to string conversion

On 24 February 2015 at 19:23, Thomas Bley wrote: > I think this is a huge bc break that will affect many applications. For > example: > > // test.php > error_reporting(E_ALL & ~E_NOTICE); > echo $_GET['value']; > > curl http://.../test.php?value=foo // ok > curl http://.../test.php?value[0]=foo&v

Re: [PHP-DEV] [RFC] [DISCUSSION] Reliable user-land CSPRNG

On Feb 24, 2015 3:08 AM, "Leigh" wrote: > > On 24 February 2015 at 10:55, Pierre Joye wrote: > > It should use the session.entropy_file setting as it aims to be the exact > > same thing. It also allows custom entropy src (better ones for higher > > demands) as well. > > I disagree. We want to tak

Re: [PHP-DEV] [RFC][VOTE] Improve array to string conversion

There are many cases where applications are not transactions safe, e.g. calling multiple external interfaces via soap, json, xml, etc. If the application suddenly stops between two external calls - where it could not stop before - you get unexpected behavior. Leigh wrote on 24.02.2015 20:29: >

Re: [PHP-DEV] Re: [RFC] Script only include/require

Hi! > Will it add a significant level of protection? No. > > Does it add protection? Yes. > > Each time we add some incremental security hardening, we make it a bit > harder to create vulnerabilities. In this case, if there were code In this case, it seems not to be much harder than changing an

Re: [PHP-DEV] Feature request and RFC

Hi! > I've made PR proposing a feature request: A new interface Sortable. > > https://github.com/php/php-src/pull/1116 > > If possible, I would like to create and RFC describing this in more detail, > and perhaps get a voting on. Can't you sort any class that provides ordered list of elements a

Re: [PHP-DEV] [RFC] [DISCUSSION] Reliable user-land CSPRNG

Pierre, >> In fact I had planned for a future RFC where we allow >> session.entropy_file to use using random_bytes(). So the "best" source >> is chosen automatically. (If you think there are better sources not >> covered by this patch, please let me know, I would like it to be >> complete) > > I r

Re: [PHP-DEV] Feature request and RFC

2015-02-24 20:49 GMT+01:00 Stanislav Malyshev : > Hi! > > > I've made PR proposing a feature request: A new interface Sortable. > > > > https://github.com/php/php-src/pull/1116 > > > > If possible, I would like to create and RFC describing this in more > detail, > > and perhaps get a voting on. >

Re: [PHP-DEV] [RFC] Script only include/require

Hi On Tuesday, February 24, 2015, Stanislav Malyshev wrote: > Hi! > > > Will it add a significant level of protection? No. > > > > Does it add protection? Yes. > > > > Each time we add some incremental security hardening, we make it a bit > > harder to create vulnerabilities. In this case, if th

Re: [PHP-DEV] [RFC] [DISCUSSION] Reliable user-land CSPRNG

On Feb 24, 2015 12:04 PM, "Anthony Ferrara" wrote: > > Pierre, > > >> In fact I had planned for a future RFC where we allow > >> session.entropy_file to use using random_bytes(). So the "best" source > >> is chosen automatically. (If you think there are better sources not > >> covered by this patc

Re: [PHP-DEV] [RFC] Script only include/require

Hi Stas, On Wed, Feb 25, 2015 at 5:33 AM, Pádraic Brady wrote: > On Tuesday, February 24, 2015, Stanislav Malyshev > wrote: > >> Hi! >> >> > Will it add a significant level of protection? No. >> > >> > Does it add protection? Yes. >> > >> > Each time we add some incremental security hardening,

Re: [PHP-DEV] [RFC] [DISCUSSION] Reliable user-land CSPRNG

Hi On 24 February 2015 at 20:04, Anthony Ferrara wrote: > If random_bytes() is harder than uniqid(), it's a non-starter. Technically, it will be harder than uniqid() if producing strictly random bytes (if output needs to be printable/readable). That's not a "bad" thing obviously! Paddy -- Pádr

Re: [PHP-DEV] [RFC] [DISCUSSION] Reliable user-land CSPRNG

Padraic, On Tue, Feb 24, 2015 at 4:17 PM, Pádraic Brady wrote: > Hi > > On 24 February 2015 at 20:04, Anthony Ferrara wrote: >> If random_bytes() is harder than uniqid(), it's a non-starter. > > Technically, it will be harder than uniqid() if producing strictly > random bytes (if output needs to

Re: [PHP-DEV] [RFC] [DISCUSSION] Reliable user-land CSPRNG

On 24 February 2015 at 20:54, Pierre Joye wrote: > On Feb 24, 2015 12:04 PM, "Anthony Ferrara" wrote: >> PERHAPS, it could be written in such a way that a PECL extension can >> alter the RNG to accommodate that usecase. But I'd be wary of that and >> core supporting userland RNGs. > > Yes, driver

Re: [PHP-DEV] [RFC] [DISCUSSION] Reliable user-land CSPRNG

Hi On 24 February 2015 at 21:33, Anthony Ferrara wrote: > Padraic, > > On Tue, Feb 24, 2015 at 4:17 PM, Pádraic Brady > wrote: >> Hi >> >> On 24 February 2015 at 20:04, Anthony Ferrara wrote: >>> If random_bytes() is harder than uniqid(), it's a non-starter. >> >> Technically, it will be harde

Re: [PHP-DEV] [RFC] [DISCUSSION] Reliable user-land CSPRNG

Padraic, >>> Technically, it will be harder than uniqid() if producing strictly >>> random bytes (if output needs to be printable/readable). >>> That's not a "bad" thing obviously! >> >> Sure. But does that indicate the need for a "random_string()" function? > > It would be more random than a stre

Re: [PHP-DEV] [RFC] Script only include/require

Hi! > They'd need to upload with a matching file type. Instead of any file Not sure what you mean by that. phar can read tars, etc. AFAIK, can't it? Also, phar archive has no requirement of being named something.phar, afaik can be also named cuteponies.gif. E.g., I just did this: 1. Created file

Re: [PHP-DEV] [RFC] [DISCUSSION] Reliable user-land CSPRNG

Hi all, On Wed, Feb 25, 2015 at 6:33 AM, Anthony Ferrara wrote: > On Tue, Feb 24, 2015 at 4:17 PM, Pádraic Brady > wrote: > > Hi > > > > On 24 February 2015 at 20:04, Anthony Ferrara > wrote: > >> If random_bytes() is harder than uniqid(), it's a non-starter. > > > > Technically, it will be ha

Re: [PHP-DEV] [RFC] Script only include/require

Hi Stas, On Wed, Feb 25, 2015 at 7:07 AM, Stanislav Malyshev wrote: > > They'd need to upload with a matching file type. Instead of any file > > Not sure what you mean by that. phar can read tars, etc. AFAIK, can't > it? Also, phar archive has no requirement of being named something.phar, > afai

Re: [PHP-DEV] [RFC] Script only include/require

Hi! > I would like to add a note for this. > Anti Virus products are detecting this type of files as "PHP malware". It looks like you are trying to convince me that PHP malware exists. I would like to save you time by notifying you I am aware of this. My disagreement is not denying PHP malware ex

Re: [PHP-DEV] [RFC] Script only include/require

Hi! > I think he means matching file "extension". File extension should > represent file type, though. You can not rely on that. I can name files anything regardless of what's in the file. > Since "pwnd.php" has ".php" extension, move_uploaded_file() refuses to > move it > to upload dir by defau

Re: [PHP-DEV] [RFC] [DISCUSSION] Reliable user-land CSPRNG

On Tue, Feb 24, 2015 at 1:39 PM, Leigh wrote: > On 24 February 2015 at 20:54, Pierre Joye wrote: >> On Feb 24, 2015 12:04 PM, "Anthony Ferrara" wrote: >>> PERHAPS, it could be written in such a way that a PECL extension can >>> alter the RNG to accommodate that usecase. But I'd be wary of that a

Re: [PHP-DEV] [RFC] Script only include/require

Hi Stas, On Wed, Feb 25, 2015 at 7:31 AM, Stanislav Malyshev wrote: > > I think he means matching file "extension". File extension should > > represent file type, though. > > You can not rely on that. I can name files anything regardless of what's > in the file. > > > Since "pwnd.php" has ".php"

Re: [PHP-DEV] [RFC] Script only include/require

Hi Stas, On Wed, Feb 25, 2015 at 7:26 AM, Stanislav Malyshev wrote: > > I would like to add a note for this. > > Anti Virus products are detecting this type of files as "PHP malware". > > It looks like you are trying to convince me that PHP malware exists. I > would like to save you time by noti

Re: [PHP-DEV] [RFC] [DISCUSSION] Reliable user-land CSPRNG

Hi Yasuo, On 24 February 2015 at 22:08, Yasuo Ohgaki wrote: > Random bytes is better. People would use it for IV or like with the > size of IV. If we use string, users loose effective bits. Suggestion was for an additional function, so random_bytes() would still be there ;). Paddy -- Pádraic

Re: [PHP-DEV] [RFC] Script only include/require

Hi Stas, On Wed, Feb 25, 2015 at 7:53 AM, Yasuo Ohgaki wrote: > require('cuteponies.gif) wouldn't work with this RFC. > move_uploaded_files() prohibits uploading PHP script. > I noticed that I should forbid destination file extension also by this > discussion. > I'll add it soon. Thank you. > O

Re: [PHP-DEV] [RFC] Script only include/require

Hi! > require('cuteponies.gif) wouldn't work with this RFC. > move_uploaded_files() prohibits uploading PHP script. You seem not to be reading the scenario. The include URL would be phar://cuteponies.gif/pwnd.php and the uploaded file would be cuteponies.gif. Your protection would not stop movin

Re: [PHP-DEV] [RFC] Script only include/require

Hi! > As far as I know, PHP is the only language that has this type of malware. > (Script embedded images) PHP is the only one malware vendors claims > it as "PHP malware". This is the fact. Which type is that? Of course only malware in PHP can be presented as "PHP malware", but I don't understa

Re: [PHP-DEV] Coercive Scalar Type Hints RFC - BC breaks

On Tue, Feb 24, 2015 at 5:23 AM, François Laupretre wrote: > I think I was not clear. *Every* 'break' I report here won't generate > anything more than E_DEPRECATED in the final implementation. By definition. > Ne need to wait for a better patch. How do you test apps with actual production data

RE: [PHP-DEV] [Discussion] Last chance for case-sensitive engine

Hi, I started the RFC because I first wanted to test the idea on the list and have a place to store every case-insensitive I could find in PHP. I stopped for several reasons : 1. The reactions were mostly negative, with a majority of 'breaks much, brings nothing' opinions, 2. Crawling through t

Re: [PHP-DEV] [RFC] [VOTE] Remove the date.timezone warning

I just closed the vote with 32: to 11 votes: the RFC is accepted. I will merge the patch in the next days. Bob > Am 16.02.2015 um 18:59 schrieb Bob Weinand : > > As announced yesterday, I put the RFC into vote now. > Voting period is 8 days, it will end 24th of February. > > The RFC is here: >

Re: [PHP-DEV] [RFC] Script only include/require

Hi, On 24 February 2015 at 22:07, Stanislav Malyshev wrote: > Hi! > >> They'd need to upload with a matching file type. Instead of any file > > Not sure what you mean by that. phar can read tars, etc. AFAIK, can't > it? Also, phar archive has no requirement of being named something.phar, > afaik

Re: [PHP-DEV] [RFC] Script only include/require

Hi, >> This RFC benefits may not be obvious for people on this list, but this >> RFC eliminates certain type of "PHP malware". PHP's script inclusion > > I can't think of any type of PHP malware that would be eliminated. At > most, the malware injection protocols have to be slightly modified to >

Re: [PHP-DEV] [RFC] Script only include/require

Hi! > Your example omitted the image validation step which would have Ah, right, and if I name it .zip, it'd be zip validation, and if I name it .pdf it'd be pdf validation, and if I name it .lol that would be LOL validation. You'd have to manually validate every type in existence and somehow inv

Re: [PHP-DEV] [RFC] Script only include/require

Hi Stas, On Wed, Feb 25, 2015 at 8:25 AM, Stanislav Malyshev wrote: > > As far as I know, PHP is the only language that has this type of malware. > > (Script embedded images) PHP is the only one malware vendors claims > > it as "PHP malware". This is the fact. > > Which type is that? Of course o

Re: [PHP-DEV] [RFC] Script only include/require

On 25 February 2015 at 00:09, Pádraic Brady wrote: > > Your example omitted the image validation step which would have > noticed your attempt to upload a phar immediately. Add that and try > again. Image validation is no defense against this type of attack: http://php.webtutor.pl/en/2011/05/13/p

Re: [PHP-DEV] [RFC] Script only include/require

Hi Dan On Wednesday, February 25, 2015, Dan Ackroyd wrote: > On 25 February 2015 at 00:09, Pádraic Brady > wrote: > > > > Your example omitted the image validation step which would have > > noticed your attempt to upload a phar immediately. Add that and try > > again. > > Image validation is no

Re: [PHP-DEV] [RFC] Script only include/require

Hi! > That was indeed my point as Yasuo has already explained earlier. Image > validation would however see a phar a mile off. How much would you bet against the possibility of a file existing that can both pass as an image file of some type and as a valid zip or tgz or tar file? Hint: don't go t

Re: [PHP-DEV] [RFC] Script only include/require

Hi Dan, On Wed, Feb 25, 2015 at 9:38 AM, Dan Ackroyd wrote: > On 25 February 2015 at 00:09, Pádraic Brady > wrote: > > > > Your example omitted the image validation step which would have > > noticed your attempt to upload a phar immediately. Add that and try > > again. > > Image validation is n

Re: [PHP-DEV] [RFC] Script only include/require

Hi! > - require/include only includes ".php" ".phar" by default. This is not true. As I repeatedly point out, your change only requires that the string passed to include would end in .php, but string passed to include and filename on filesystem are very different things, they do not have to be t

Re: [PHP-DEV] [RFC] Script only include/require

Hi On Wednesday, February 25, 2015, Stanislav Malyshev wrote: > Hi! > > > Your example omitted the image validation step which would have > > Ah, right, and if I name it .zip, it'd be zip validation, and if I name > it .pdf it'd be pdf validation, and if I name it .lol that would be LOL > valida

Re: [PHP-DEV] [RFC] Script only include/require

Hi Stas, On Wed, Feb 25, 2015 at 9:52 AM, Stanislav Malyshev wrote: > > - require/include only includes ".php" ".phar" by default. > > This is not true. As I repeatedly point out, your change only requires > that the string passed to include would end in .php, but string passed > to include and

Re: [PHP-DEV] [RFC] Script only include/require

On Wed, Feb 25, 2015 at 9:59 AM, Yasuo Ohgaki wrote: > Are you saying current PHP allows > include('zip://...') or include('input://...')? > Correction. include('input://..') should be include('php://input') (and like) -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

Hi internais, This is just a friendly reminder that, according the the previously established voting duration of 14 days, the voting for Group Use declarations will close in exactly 17 hours counting from now. Thanks.

RE: [PHP-DEV] Coercive Scalar Type Hints RFC - BC breaks

Hi, > De : Pierre Joye [mailto:pierre@gmail.com] > > How do you test apps with actual production data? What a given code is > being fed with in production, everywhere, using random > application&users specific data or inputs. I personally have no codebase to test. These results come from a si

Re: [PHP-DEV] [RFC] [DISCUSSION] Reliable user-land CSPRNG

Hi Padraic, On Wed, Feb 25, 2015 at 7:54 AM, Pádraic Brady wrote: > On 24 February 2015 at 22:08, Yasuo Ohgaki wrote: > > Random bytes is better. People would use it for IV or like with the > > size of IV. If we use string, users loose effective bits. > > Suggestion was for an additional functi

Re: [PHP-DEV] [Discussion] Last chance for case-sensitive engine

Hi Francois, On Wed, Feb 25, 2015 at 8:45 AM, François Laupretre wrote: > > I stopped for several reasons : > > 1. The reactions were mostly negative, with a majority of 'breaks much, > brings nothing' opinions, > > 2. Crawling through the code, I discovered that code to handle case > insensitivi

[PHP-DEV][RFC][DISCUSSION] Context Sensitive Lexer v0.4

Hi, I'd like to put the "Context Sensitive Lexe" RFC into discussion again. As promised, the RFC was reverted to it's previous less ambitious version, this time offering no drawbacks like the one pointed by Nikita. RFC: https://wiki.php.net/rfc/context_sensitive_lexer PR: https://github.com/php/

Re: [PHP-DEV] [RFC] Script only include/require

Hi! > Are you saying current PHP allows > include('zip://...') or include('input://...')? Neither zip not phar are classified as url handlers. Both have is_url to 0. > Then this is serious bug. I'll fix it also. This would be another big BC break, as this would mean you can not use phar streams

Re: [PHP-DEV] Annotations in PHP7

On 02/21/2015 03:35 PM, Pavel Kouřil wrote: I know you could wrap it in your code, but that would still mean there would probably be multiple implementations of Annotations in the "wild", instead of a good complete functionality in the language itself. I know PHP is not primarily an OOP languag

Re: [PHP-DEV] [RFC] Script only include/require

Hi Stas, On Wed, Feb 25, 2015 at 12:19 PM, Stanislav Malyshev wrote: > > Are you saying current PHP allows > > include('zip://...') or include('input://...')? > > Neither zip not phar are classified as url handlers. Both have is_url to 0. > > > Then this is serious bug. I'll fix it also. > > Thi

Re: [PHP-DEV] [RFC] Script only include/require

Hi! > I have to at least php:// > php://input or php://stdin > allows attacker script execution via POST if it's allowed > by allow_url_include=On. allow_url_include=On means it's allowed. That's what "on" setting is for. Production setting should always be "off". -- Stas Malyshev smalys...@gm

Re: [PHP-DEV] [RFC] [DISCUSSION] Reliable user-land CSPRNG

On 02/24/2015 07:41 PM, Yasuo Ohgaki wrote: Hi Padraic, On Wed, Feb 25, 2015 at 7:54 AM, Pádraic Brady wrote: On 24 February 2015 at 22:08, Yasuo Ohgaki wrote: Random bytes is better. People would use it for IV or like with the size of IV. If we use string, users loose effective bits. Sugg

  1   2   >