Actually, the solution I was envisioning would not allow any access to
fsockopen() or other remote streams access things inside a user stream
wrapper.
Are you sure you can evaluate ALL engine functions that allow accessing
remote data? Looks dangerously like safe mode...
--
Stanislav Malyshev,
Stanislav Malyshev wrote:
>> In my opinion, it would be a pity to lose the design benefits of stream
>> wrappers in the effort to gain more security when security can be gained
>> without losing the benefits. I think it would be good to allow
>> disabling all urls as Stefan suggested, but if there
allow_url_include has been bashed lately for being "not good enough",
and there is a kernel of truth to that, though where the ultimate blame
falls if of course a touchy subject.
So rather than continue the fight over who's shoulders the job of
security should fall on, how about the attached p
Hi,
First of all I admit I'm no PHP security expert or PHP internals expert
or anything, so please don't flame me if I say something stupid.
Wouldn't simply adding a flag to allow url's (which includes all '*://'
streams), in functions that opens streams be enough? For example:
fopen($file, 'r')
Hello Evert,
assuming you mean that as an array cast you were wrong. If you convert a
SimpleXML instance to an array you get either the current element, the
current attribute or the text or all elements or all attributes. For
ArrayObject/ArrayIterator you would get either the properties or a copy
In my opinion, it would be a pity to lose the design benefits of stream
wrappers in the effort to gain more security when security can be gained
without losing the benefits. I think it would be good to allow
disabling all urls as Stefan suggested, but if there is a way to
restrict to truly local
Ignore this message if it doesn't make sense..
wouldn't this essentially be the same as __toArray() ?
Evert
Marcus Boerger wrote:
Hello Michael,
ok current name and other options in one list:
1) get_debug_info()
2) get_debug_hash()
3) get_dump_vars()
4) get_dump_hash()
does this list contai
Hello Michael,
ok current name and other options in one list:
1) get_debug_info()
2) get_debug_hash()
3) get_dump_vars()
4) get_dump_hash()
does this list contain anythign you like?
best regards
marcus
Tuesday, January 16, 2007, 8:32:41 AM, you wrote:
> Marcus Boerger wrote:
>> Hello internal
Christian Schneider wrote:
> Do you think the configure script should be changed? I'm not sure if my
> version of the test works on the system where the original test was
> developed.
https://overlays.gentoo.org/proj/php/browser/patches/php-patches/4.4.4/4.4.4/php4.4.4-gcc_inline_floor.patch
That
I tracked down the failure of test ext/standard/tests/math/bug24142.phpt
when I tried PHP 4.4.5RC1 and found out the following: The brokenness
test in the configure script, namely
#include
int main() {
return floor(0.045*pow(10,2) + 0.5)/10.0 != 0.5;
}
didn't work properly for me. I chan
Hi,
On 1/16/07, Mateusz Loskot <[EMAIL PROTECTED]> wrote:
I'm going to port libgd library to Windows CE platform.
I've already discussed this subject with Pierre-A. Joye - current
maintainer of libgd.
Pierre approved this idea and is promoting me to libgd for Windows CE
port maintainer.
So, he a
I'm going to port libgd library to Windows CE platform.
I've already discussed this subject with Pierre-A. Joye - current
maintainer of libgd.
Pierre approved this idea and is promoting me to libgd for Windows CE
port maintainer.
So, he asked me to request the CVS account.
-- Mateusz
--
PHP Inter
On Tue, 16 Jan 2007, Arnold Daniels wrote:
> Yes sure you are right, but there was some other code which I replaced
> with printf to show where the problem lies. The printf not in the actual
> code, only in the e-mail :).
> I'm very sure that the problem lies in the ret != NULL. Function
> zend_pa
Hi,
Yes sure you are right, but there was some other code which I replaced
with printf to show where the problem lies. The printf not in the actual
code, only in the e-mail :).
I'm very sure that the problem lies in the ret != NULL. Function
zend_parse_parameters() puts a strange value in ret, whe
Ah off couse,
It's not giving the segmentation fault on the first test. Thats even
stranger. It appears that the system admin had updated the kernel, than
updated some more software and than put back the old kernel. It's still
strange.
Arnold
Sebastian Bergmann wrote:
> Arnold Daniels wrote:
>
Hello Derick,
I changed the code now to be easier understandable. In the patch
the following happens. In the two if cases properties get initialized
and in the third case where none of the ifs apply properties will remain
NULL. Now in the later code is_temp isonlybeingused if properties is not
N
16 matches
Mail list logo
