On Sat, May 19, 2007 4:42 am, Cristian Rodriguez wrote:
>>2007/5/18, Stanislav Malyshev <[EMAIL PROTECTED]>:
>> Sane hosters do not rely on general-purpose language to provide
>> security, they use OS and hardware designed for exactly that
>> purpose. ;)
>
> unfortunately hosters has to equilibrate
On Sat, May 19, 2007 3:00 am, Stefan Esser wrote:
>
>> If you are aware of some security problems in current PHP sources
>> you
>> are as always welcome to report them and they will be fixed. I think
>> everybody here as always are thankful for any help we can get.
> Ohh BTW. I am aware of many sec
Why is it that you all fight worse than my 3rd year old cousins? I
don't hold any authority or figure what so ever, but I watch
internals as a developer to be forewarned, but really, all I see is a
bunch of children fighting with each other.
Stefan has made contributions and has helped...
On Sat, May 19, 2007 4:00 am, Stefan Esser wrote:
> Antony is very fast with assigning bugs to persons that have nothing
> todo with them.
> I believe there is still a bug assigned to me because in Antony's
> world
> I am responsible for it, while infact
> my commit was in a version AFTER the one t
On Fri, May 18, 2007 6:47 pm, Cristian Rodriguez wrote:
> 2007/5/18, Greg Beaver <[EMAIL PROTECTED]>:
>
>> > include $_GET['dumb'];
>> ?>
>>
>
> What about permanently removing this (mis) "feature" ?? , Im yet to
> hear any valid reason or example to continue to permit this remote
> include thingy,
On Fri, May 18, 2007 10:51 am, Greg Beaver wrote:
> The solution:
> =
> Add a new function: stream_wrapper_set_local()
So, basically, your function would be similar to:
"I'm removing the safety from the gun with which I might shoot myself
in the foot."
:-) :-) :-)
Would it be applie
Dear Kevin,
you are just ridiculous. Educate yourself WHO is responsible for
improved PHP security.
Stefan Esser
> This one time, at band camp, Stefan Esser <[EMAIL PROTECTED]> wrote:
>
>
>> Stop flooding my inbox with your unqualified comments.
>> You can write the patch yourself, can you?
>>
This one time, at band camp, Stefan Esser <[EMAIL PROTECTED]> wrote:
> Stop flooding my inbox with your unqualified comments.
> You can write the patch yourself, can you?
> Or can't you? Then shut the fuck up.
I'm not the one whining about nothing being done.
This constant stream of dribble about
This one time, at band camp, Stefan Esser <[EMAIL PROTECTED]> wrote:
> The whole filter problematic is still unsolved. The filter hooks were
> still not moved into php_register_variable_ex so that they
> cannot be bypassed by mistake of a 3rd party PHP extension that
> implements another POST con
Stanislav Malyshev schrieb:
> So here we go again - a lot of time spent to write lengthy emails
> about how bad this and that person or PHP Group as a whole is, or to
> hint about multiple problems without getting into details - and when
> it comes to details - no, that's no fun anymore. Should we
And I think I repeated myself often enough.
So here we go again - a lot of time spent to write lengthy emails about
how bad this and that person or PHP Group as a whole is, or to hint
about multiple problems without getting into details - and when it comes
to details - no, that's no fun anymo
The issue with this remote url include thingy is that is hard to find
a valid use case ..does anyone has a **real** one ? why it was
I believe there is.
introduced in the first place..?? no, Im not talking about crippling
As I already said, it was never introduced. What was introduced is
st
Oliver Block wrote:
> Hello Greg,
>
> I would first ask the following question:
>
> Why should the user be prevented to include remote site code?
>
> #1: hoster and users are equal
>
>
> The hoster - as the "person" providing for the php infrastr
Hello Greg,
I would first ask the following question:
Why should the user be prevented to include remote site code?
#1: hoster and users are equal
The hoster - as the "person" providing for the php infrastructure - is trying
to prevent the user
2007/5/18, Stanislav Malyshev <[EMAIL PROTECTED]>:
Sane hosters do not rely on general-purpose language to provide
security, they use OS and hardware designed for exactly that purpose. ;)
unfortunately hosters has to equilibrate security vs/usability for
their customers.. so disaloowing 100% acc
Stanislav Malyshev schrieb:
> What you see as a war, other see as a discussion. I think if you tried
> viewing it as figuring out common solution and discussing options and
> not combat it would make sense to you too, probably.
Maybe I read a different internals list. Just read the World vs. Pierre
Everyone watching the PHP internals list can see how true it is. One war
after another, because some PHP developers are more equal than others.
What you see as a war, other see as a discussion. I think if you tried
viewing it as figuring out common solution and discussing options and
not comba
On 19/05/2007, at 1.47, Cristian Rodriguez wrote:
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
Ohh BTW. I am aware of many security problems in current PHP, actually
the whole world
is, because there are still a lot of "local" vulnerabilities unfixed
We seem to be in a disagreement about what security vulnerability is.
However, it is not very important since bugs are to be fixed anyway.
Stanislav Malyshev schrieb:
>> Yes I think you do not need to repeat that there is no such thing as a
>> PHP leadership.
>
> I don't need to repeat it because I never said that and it's not true.
> There's difference between leadership and not having disagreement or
> discussion, even if some fail
> If you are aware of some security problems in current PHP sources you
> are as always welcome to report them and they will be fixed. I think
> everybody here as always are thankful for any help we can get.
Ohh BTW. I am aware of many security problems in current PHP, actually
the whole world
is,
Yes I think you do not need to repeat that there is no such thing as a
PHP leadership.
I don't need to repeat it because I never said that and it's not true.
There's difference between leadership and not having disagreement or
discussion, even if some fail to see it.
--
Stanislav Malyshev, Ze
> I wonder if you actually aware of the fact that there's no such single
> entity as "PHP developers" and each of them is entirely different living
> human? And these humans sometimes are in disagreement and some of them
> are wrong? And then the thing called "discussion" happens and it's not
> al
At the moment they are very predictable. You send them a security bug
and first they try to tell you that you are totally wrong (because
you made a
I wonder if you actually aware of the fact that there's no such single
entity as "PHP developers" and each of them is entirely different living
hum
Stanislav Malyshev wrote:
>> allow_url_(include|fopen) applies to them. As such, because
>> allow_url_(include|fopen) are disabled by default in PHP 6, this will
>
> Disabling allow_url_fopen by default is the second mistake. What's wrong
> with it? Wasn't the sole reason for having allow_url_inc
Christian,
I suggest that you simply stop arguing with PHP developers about
security issues.
The problem is that they don't understand them. They are too arrogant.
They actually
believe they know everything better.
In such a situation there is only one healing. Stop giving them tips and
let them
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
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
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,
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
39 matches
Mail list logo
