On 5/18/07, Antony Dovgal <[EMAIL PROTECTED]> wrote:
I can see 47 open bug reports assigned to you (this is bugs.php.net only, there
are also 25+ bug reports in PECL).
Most of the reports are COM, PDO or streams related. Do you still maintain
these extensions?
If no, please say so, we'll start
What about permanently removing this (mis) "feature" ?? , Im yet to
You can't remove this feature, unless you write separate file access
layer for include and for the rest of the language. You can permanently
set allow_url_include to 0, but if it's 0 by default it's more/less the
same.
--
St
I think I have a solution that would allow user streams in PHP 6 and
still satisfy paranoid hosters.
s/paranoid/sane/g
Sane hosters do not rely on general-purpose language to provide
security, they use OS and hardware designed for exactly that purpose. ;)
yes, agree, but the remote "inclu
2007/5/18, Greg Beaver <[EMAIL PROTECTED]>:
Hi,
I think I have a solution that would allow user streams in PHP 6 and
still satisfy paranoid hosters.
s/paranoid/sane/g
as it is still possible through fsockopen() and
other methods to access the outside world.
with a "tiny" :) difference, re
2007/5/18, Greg Beaver <[EMAIL PROTECTED]>:
What about permanently removing this (mis) "feature" ?? , Im yet to
hear any valid reason or example to continue to permit this remote
include thingy, all examples I have seen are bogus and broken.. does
anyone really think there are valid use case
At least 2% speedup on attached script.
2% is not that impressive... Would it be better on complex strings?
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/uns
Stanislav Malyshev wrote:
> oh, and I forgot another thing:
>
> 5. Have some function like stream_is_remote() which could check URL for
> remote-ness,
> so that the responsible stream wrapped would not rely on fopen erroring
> out.
> I couldn't locate such function, so if it isn't there it should
Documentation and Norwegian translation of the PHP Manual (phpdoc and phpdoc-no)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
oh, and I forgot another thing:
5. Have some function like stream_is_remote() which could check URL for
remote-ness,
so that the responsible stream wrapped would not rely on fopen erroring out.
I couldn't locate such function, so if it isn't there it should be added.
I think the problem could
I think the problem could be solved this way:
0. allow_url_include and allow_url_fopen renamed to allow_remote_include
and allow_remote_fopen (not really necessary, just much cleaner, if you
don't like it, ignore it for now).
1. By default, allow_remote_inclue=0, allow_remote_fopen=1
2. Stream
If I understand well, the goal here is not to mark remote stream
wrappers as local and, thus, bypass remote protection. The goal is to
be able to mark intrinsically-local stream wrappers as local. The
How'd you achieve the distinction? If you define the stream, don't you
want to make it work? I
The problem:
Because there is no way to be sure that a userspace stream is not
remote, all userspace streams are marked as remote and so
I think that's the first mistake. Marking all streams remote because
some of them could do remote access is like refusing to execute all user
co
> From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED]
> I don't think this is a good idea. If you need to access external
> data use fsockopen or stream code or even cURL. Creating
> filters just to add bypasses for them seems silly to me.
If I understand well, the goal here is not to mark remo
I think it is a very good solution.
IMO, we don't have to go further in protecting the user against himself, even
if allowing to switch the local/remote flag on streams from user space won't
please to everybody...
Francois
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
On Fri, 18 May 2007, Rasmus Lerdorf wrote:
> Stanislav Malyshev wrote:
> > Looks like we have a precedence bug in the parser rules there.
> > Fortunately it's quite easy to fix, for example writing the rules as:
> >
> > |'+' expr %prec T_INC
> > |'-' expr %prec T_INC
> >
> > seem
I don't think this is a good idea. If you need to access external
data use fsockopen or stream code or even cURL. Creating filters just
to add bypasses for them seems silly to me.
On 18-May-07, at 11:51 AM, Greg Beaver wrote:
Hi,
I think I have a solution that would allow user streams in
Hi,
I think I have a solution that would allow user streams in PHP 6 and
still satisfy paranoid hosters.
First, let me clarify what I see as the assumed problem, so that if I
have missed something, you will correct my assumption:
My assumption:
==
The point of allow_url_include/allow
On 18.05.2007 18:14, Pierre wrote:
Hi Tony,
On 5/18/07, Antony Dovgal <[EMAIL PROTECTED]> wrote:
Hello Wez.
On 18.05.2007 17:26, Wez Furlong wrote:
> On 5/17/07, Cristian Rodriguez <[EMAIL PROTECTED]> wrote:
>> 3. pressure oever developers does not make any good, is disrespectul,
>> specially
Hi Tony,
On 5/18/07, Antony Dovgal <[EMAIL PROTECTED]> wrote:
Hello Wez.
On 18.05.2007 17:26, Wez Furlong wrote:
> On 5/17/07, Cristian Rodriguez <[EMAIL PROTECTED]> wrote:
>> 3. pressure oever developers does not make any good, is disrespectul,
>> specially when they are not getting paid to wo
Hello Wez.
On 18.05.2007 17:26, Wez Furlong wrote:
On 5/17/07, Cristian Rodriguez <[EMAIL PROTECTED]> wrote:
3. pressure oever developers does not make any good, is disrespectul,
specially when they are not getting paid to work.
One of the points that Andrei was trying to make was that if you
On 5/18/07, Wez Furlong <[EMAIL PROTECTED]> wrote:
On 5/17/07, Cristian Rodriguez <[EMAIL PROTECTED]> wrote:
> 3. pressure oever developers does not make any good, is disrespectul,
> specially when they are not getting paid to work.
One of the points that Andrei was trying to make was that if yo
On 5/17/07, Cristian Rodriguez <[EMAIL PROTECTED]> wrote:
3. pressure oever developers does not make any good, is disrespectul,
specially when they are not getting paid to work.
One of the points that Andrei was trying to make was that if you
really don't have time for something, you should say
Sorry, php-internal guys, just a small :) reply to Greg's message, and we'll
take it off list, as Greg is right: it does not have much to do with php
internals any more...
> From: Greg Beaver [mailto:[EMAIL PROTECTED]
> Please STOP spreading misinformation. phar is *not* a
> deployment tool,
Stanislav Malyshev wrote:
> Looks like we have a precedence bug in the parser rules there.
> Fortunately it's quite easy to fix, for example writing the rules as:
>
> |'+' expr %prec T_INC
> |'-' expr %prec T_INC
>
> seems to work. Any reason not to?
I think this should go in. I
At least 2% speedup on attached script.
Thanks. Dmitry.
> -Original Message-
> From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 17, 2007 8:52 PM
> To: Dmitry Stogov
> Cc: 'Matt Wilmas'; internals@lists.php.net; 'Andi Gutmans'
> Subject: Re: [PHP-DEV] [PATCH] Major
25 matches
Mail list logo
