[PHP-DEV] Preload scripts and preloaded scripts only options

Hi all, As some of you know that I'm trying to to eliminate script inclusion attack. I come up with another idea which may have consensus. PHP compiler is fast enough for almost all apps without script preloading. However, large sites take advantage of opcache_compile_file() to maximize the perf

RE: [PHP-DEV] Preload scripts and preloaded scripts only options

> De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo > Ohgaki > > As some of you know that I'm trying to to eliminate script inclusion attack. > I come up with another idea which may have consensus. > > PHP compiler is fast enough for almost all apps without script preloading.

RE: [PHP-DEV] Preload scripts and preloaded scripts only options

None of this whitelisting-by-filename would be practical for our setup. Have a look at what Smarty does with compiled templates and cached pages: PHP includes generated on the fly, with filenames that are not known in advance. For such usage a whitelisting per realpath prefix, would be the only rea

Re: [PHP-DEV] Preload scripts and preloaded scripts only options

On Sat, 2015-05-16 at 15:32 +0200, Patrick Schaaf wrote: > None of this whitelisting-by-filename would be practical for our setup. > Have a look at what Smarty does with compiled templates and cached pages: > PHP includes generated on the fly, with filenames that are not known in > advance. For suc

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

I want to talk about the BC impact of what has been discussed. Currently the meaning of this code is to catch all possible exceptions, because all exceptions *must* extend `\Exception`: } catch (Exception $e) { By making some other root exception you just broke all the code that is *appropri

Re: [PHP-DEV] Preload scripts and preloaded scripts only options

Am 16.05.2015 16:32 schrieb "Johannes Schlüter" : > > That whitelist is called open_basedir. > http://php.net/manual/en/ini.core.php#ini.open-basedir Ahem. open_basedir is neither a list, nor is is restricted to restricting include/require, which is the topic Yasuo is musing to do something about.

Re: [PHP-DEV] Bug #69640 Unhandled EngineExceptions thrown from userland do not produce any output

Hey: On Sat, May 16, 2015 at 1:41 AM, Dan Ackroyd wrote: > On 15 May 2015 at 17:12, Xinchen Hui wrote: >>> How would that work when people want to write unit/integration tests >>> to test the behaviour of a module when an EngineException is thrown? >>> >>> If you can't create a certain type of e

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

On 16/05/2015 15:40, Levi Morrison wrote: I want to talk about the BC impact of what has been discussed. Currently the meaning of this code is to catch all possible exceptions, because all exceptions *must* extend `\Exception`: } catch (Exception $e) { By making some other root exception

Re: [PHP-DEV] Bug #69640 Unhandled EngineExceptions thrown from userland do not produce any output

On Fri, May 15, 2015 at 11:41 AM, Dan Ackroyd wrote: > On 15 May 2015 at 17:12, Xinchen Hui wrote: > >> How would that work when people want to write unit/integration tests > >> to test the behaviour of a module when an EngineException is thrown? > >> > >> If you can't create a certain type of e

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

> This was the subject of a separate vote in the RFC, which passed by 39 votes > to 19. https://wiki.php.net/rfc/engine_exceptions_for_php7 The subject of > discussion at present is the exact naming of the various classes/interfaces, > not the general nature of the hierarchy. There's nothing that

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

On Sat, May 16, 2015 at 11:51 AM, Levi Morrison wrote: >> This was the subject of a separate vote in the RFC, which passed by 39 votes >> to 19. https://wiki.php.net/rfc/engine_exceptions_for_php7 The subject of >> discussion at present is the exact naming of the various classes/interfaces, >> not

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

Hi! > There's nothing that prevents us from reneging on that by another > vote. If it's a bad decision backed by logical arguments then we can That's a pretty big if, given that your only argument - that it is a BC break - is incorrect, as in fact the set of exceptions caught before and after cha

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

On Sat, May 16, 2015 at 12:28 PM, Stanislav Malyshev wrote: > Hi! > >> There's nothing that prevents us from reneging on that by another >> vote. If it's a bad decision backed by logical arguments then we can > > That's a pretty big if, given that your only argument - that it is a BC > break - is

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

On Sat, May 16, 2015 at 12:28 PM, Stanislav Malyshev wrote: > Hi! > >> There's nothing that prevents us from reneging on that by another >> vote. If it's a bad decision backed by logical arguments then we can > > That's a pretty big if, given that your only argument - that it is a BC > break - is

Re: [PHP-DEV] Bug #69640 Unhandled EngineExceptions thrown from userland do not produce any output

On 16 May 2015 at 17:00, Ryan Pallas wrote: > Why do you want to test parse exceptions? Lint your code before you run it > and you won't have any. ... maybe I'm missing something > obvious, Yeah, there's been a misunderstanding. I'm not talking about wanting to test whether my code generates par

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

On Sat, May 16, 2015 at 12:44 PM, Levi Morrison wrote: > On Sat, May 16, 2015 at 12:28 PM, Stanislav Malyshev > wrote: >> Hi! >> >>> There's nothing that prevents us from reneging on that by another >>> vote. If it's a bad decision backed by logical arguments then we can >> >> That's a pretty big

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

Hi! > You are incorrect. The set of exceptions that `catch (Exception)` > catches is all exceptions by its definition. By altering it to no There's no such definition. It's invented to serve your point, which makes it circular logic. catch(Exception) catches everything that descends from Excepti

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

Hi! > The key is that I feel like the voting body wasn't well informed. It's > not because I lost; rather it's because I feel like the people voting > yes didn't actually understand the issues at play. There is a big > difference between that and revoting after a vote didn't go my way as > an effo

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

Hi! >> The thrown object must be an instance of the Exception class or a subclass >> of Exception. This is still true for objects that are thrown from userspace, AFAIK. If not, we can make it true, I have no objection to it. This however gives your no guarantee catch(Exception) catches everythin

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

On Sat, May 16, 2015 at 1:13 PM, Stanislav Malyshev wrote: > Hi! > >> The key is that I feel like the voting body wasn't well informed. It's >> not because I lost; rather it's because I feel like the people voting >> yes didn't actually understand the issues at play. There is a big >> difference b

Re: [PHP-DEV] Preload scripts and preloaded scripts only options

Hi! > In addition, how about have a option that allows preloaded script only? I imagine it would be not hard to do with an extension overriding compile_file, etc. the same way opcache does? This way it can be implemented as independent functionality not needing modification of the engine or opca

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

On 16/05/2015 19:44, Levi Morrison wrote: On Sat, May 16, 2015 at 12:28 PM, Stanislav Malyshev wrote: Hi! There's nothing that prevents us from reneging on that by another vote. If it's a bad decision backed by logical arguments then we can That's a pretty big if, given that your only argume

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

On 16/05/2015 20:15, Levi Morrison wrote: The difference is that as time goes on and I've written code for PHP 7 I was hit by this issue. It's an even bigger issue than even I realized during voting. How many people who voted on that issue have played with the code from both scenarios? Few, I can

Re: [PHP-DEV] PR 1217: Add support for upload files from buffer string in curl extenion

Hi! PR: https://github.com/php/php-src/pull/1283 -- With regards, Alexander Moskalev ir...@irker.net ir...@php.net a.moska...@corp.badoo.com

[PHP-DEV] Throwable patch(es) and finalizing the story

Hi! I am assuming we have broad consensus about the move from BaseException to Throwable. I've looked at the patch at https://github.com/php/php-src/pull/1282 and it seems pretty close to what we want to me. The only difference is that https://wiki.php.net/rfc/throwable says Throwable is an interf

Re: [PHP-DEV] Preload scripts and preloaded scripts only options

Hi Francois, On Sat, May 16, 2015 at 10:04 PM, François Laupretre wrote: > > De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo > > Ohgaki > > > > As some of you know that I'm trying to to eliminate script inclusion > attack. > > I come up with another idea which may have cons

Re: [PHP-DEV] Preload scripts and preloaded scripts only options

Hi Patrick, On Sat, May 16, 2015 at 10:32 PM, Patrick Schaaf wrote: > None of this whitelisting-by-filename would be practical for our setup. > Have a look at what Smarty does with compiled templates and cached pages: > PHP includes generated on the fly, with filenames that are not known in > ad

Re: [PHP-DEV] Preload scripts and preloaded scripts only options

Hi Johannes, On Sat, May 16, 2015 at 11:32 PM, Johannes Schlüter wrote: > That whitelist is called open_basedir. > http://php.net/manual/en/ini.core.php#ini.open-basedir > I'm trying to eliminate risks of script inclusion attack. open_basedir is not good enough to prevent include('/path/to/upl

Re: [PHP-DEV] Preload scripts and preloaded scripts only options

Hi Stas, On Sun, May 17, 2015 at 4:53 AM, Stanislav Malyshev wrote: > > In addition, how about have a option that allows preloaded script only? > > I imagine it would be not hard to do with an extension overriding > compile_file, etc. the same way opcache does? > > This way it can be implemented

Re: [PHP-DEV] Proposal: interfaces for object to scalar type casting

Hi! > So, what do you think of a set of interfaces that allow userland objects to > be used as scalar types? > > Some simple examples in PHP here: > https://gist.github.com/guiwoda/5d16c8fb97d29e476d20 We already have CastToString, it's __toString. I'm not sure we need a named interface for that

Re: [PHP-DEV] Re: Proposal: interfaces for object to scalar type casting

Hi! > One of the biggest problems is that it's not always clear which > conversion should be used; consider, for instance, > > $obj1 + $obj2 > > where __toInt() as well as __toFloat() might make sense. If both are object, I would rather not use either conversion, I'd use operator support inst

Re: [PHP-DEV] Preload scripts and preloaded scripts only options

Hi! > Right. Users could implement whitelist by themselves. I'm not talking about userspace implementation, I'm talking about extension - which would make it work with any code as soon as extension is loaded. > However, isn't it nice to have this feature? It does not have any > performance penal

Re: [PHP-DEV] Throwable patch(es) and finalizing the story

Hi All, On Sun, May 17, 2015 at 5:57 AM, Stanislav Malyshev wrote: > I am assuming we have broad consensus about the move from BaseException > to Throwable. I've looked at the patch at > I would like to add note that the name "BaseException" breaks too many apps. Someone researched this in prev

Re: [PHP-DEV] Context Sensitive Language RFC - Implementation Candidate

On Mon, Apr 20, 2015 at 5:32 PM, Marcio Almada wrote: > Hi, > > The Context Sensitive Lexer RFC > passed :) and by the > time of the voting phase, we decided to vote for the feature only and later > discuss quality analysis on the implementations

Re: [PHP-DEV] Throwable patch(es) and finalizing the story

On Sat, May 16, 2015 at 10:57 PM, Stanislav Malyshev wrote: > Hi! > > I am assuming we have broad consensus about the move from BaseException > to Throwable. I've looked at the patch at > https://github.com/php/php-src/pull/1282 and it seems pretty close to > what we want to me. The only differen

Re: [PHP-DEV] Throwable patch(es) and finalizing the story

Hi! > Sorry for going a bit off-topic here, but why does this need to be > resolved for the first alpha? If I'm not mistaken, we do feature freeze Because it's a pretty deep language change and we don't want to release stuff that has such deep change pending. However, I don't really want to spend

Re: [PHP-DEV] Preload scripts and preloaded scripts only options

Hi Stas, On Sun, May 17, 2015 at 6:16 AM, Stanislav Malyshev wrote: > > Right. Users could implement whitelist by themselves. > > I'm not talking about userspace implementation, I'm talking about > extension - which would make it work with any code as soon as extension > is loaded. > I see. Int

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

On Sat, May 16, 2015 at 2:17 PM, Rowan Collins wrote: > On 16/05/2015 20:15, Levi Morrison wrote: >> >> The difference is that as time goes on and I've written code for PHP 7 >> I was hit by this issue. It's an even bigger issue than even I >> realized during voting. How many people who voted on t

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

On Sat, May 16, 2015 at 5:44 PM, Levi Morrison wrote: > On Sat, May 16, 2015 at 2:17 PM, Rowan Collins > wrote: >> On 16/05/2015 20:15, Levi Morrison wrote: >>> >>> The difference is that as time goes on and I've written code for PHP 7 >>> I was hit by this issue. It's an even bigger issue than

Re: [PHP-DEV] Context Sensitive Language RFC - Implementation Candidate

Hi! > Sorry for late response, forgot about this RFC. I've only glanced over it, > but the patch looks okay from the technical side. > > No problem :) there are other more important issues being discussed that should be prioritized, specially your engine exception RFC. > The thing that's bother

Re: [PHP-DEV] Bug #69640 Unhandled EngineExceptions thrown from userland do not produce any output

On 15 May 2015 at 14:38, Xinchen Hui wrote: > I'd prefer to > disallow initializing a engine exception from user land.. > like if you try to initialize a engine/type/parser exception, an E_ERROR > of: >what do you think? Someone reminded me that TypeExceptions are almost certainly going

[PHP-DEV] Re: Throwable patch(es) and finalizing the story

Hello! I’ve made another version that I believe is what Sebastian intended in the first place: Throwable as an interface, with Exception and Error being separate classes. Throwable is implemented to prevent user-land code from implementing it. https://github.com/trowski/php-src/tree/throwable-

Re: [PHP-DEV] Re: Throwable patch(es) and finalizing the story

Hi! > I’ve made another version that I believe is what Sebastian intended > in the first place: Throwable as an interface, with Exception and > Error being separate classes. Throwable is implemented to prevent > user-land code from implementing it. > > https://github.com/trowski/php-src/tree/thro

Re: [PHP-DEV] Throwable patch(es) and finalizing the story

On 05/16/2015 10:57 PM, Stanislav Malyshev wrote: > I am assuming we have broad consensus about the move from BaseException > to Throwable. I've looked at the patch at > https://github.com/php/php-src/pull/1282 and it seems pretty close to > what we want to me. The only difference is that > https:/

Re: [PHP-DEV] Throwable patch(es) and finalizing the story

On 05/17/2015 12:15 AM, Stanislav Malyshev wrote: > Where is it? I'd like to see it. https://github.com/php/php-src/pull/1284 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Throwable patch(es) and finalizing the story

Submitted the pull request: https://github.com/php/php-src/pull/1284 I’m not 100% sure on using the name Error, but Java uses a similar name scheme, so it isn’t without precedent and it keeps the names shorter. I also have a branch that prevents user s

Re: [PHP-DEV] Throwable patch(es) and finalizing the story

I tried to keep the implementation simpler in the first PR, but I think the second I submitted is much better and should be closer to what you had in mind. The second PR does not prevent user space code from instigating Error, but I do have another branch that does prevent it (same behavior as t