PHP 4 Bug Database summary - http://bugs.php.net
Num Status Summary (665 total including feature requests)
===[*Graphics related]
33484 Open Rendered Text gets Blocks around characters
=
On Mon, 27 Jun 2005, Yasuo Ohgaki wrote:
> I think most of us can agree following statement
>
> "allow_url_fopen = ON" is dangerous and the feature is not
> useful most of the times.
I disagree. With proper filtering, or using non-user-supplied
information there is no problem.
Derick
--
Deri
On Mon, 27 Jun 2005, Yasuo Ohgaki wrote:
> Since release_sysvsem_sem has error message while releasing acquired
> semaphores (both PHP_4_4 and PHP_5_1), it may end up with semaphore
> leak when error handler is used.
>
> The error message is useful for debugging, so the error message
> output sho
Derick Rethans wrote:
> On Mon, 27 Jun 2005, Yasuo Ohgaki wrote:
>
>
>>I think most of us can agree following statement
>>
>>"allow_url_fopen = ON" is dangerous and the feature is not
>>useful most of the times.
>
>
> I disagree. With proper filtering, or using non-user-supplied
> information
I think most of us can agree following statement
"allow_url_fopen = ON" is dangerous and the feature is not
useful most of the times.
No, allow_url_fopen = ON is not dangerous and it is a very useful
feature when you want to fopen() a remote URL. What you may consider
dangerous is that URLs w
allow_url_fopen is a PHP_INI_SYSTEM flag, meens you can't change it with
.htaccess
- mike
Unknown W. Brackets wrote:
Why not simply disable allow_url_fopen on your server or servers?
With it set off, you get these errors:
Warning: main() [function.main]: URL file-access is disabled in the
On Mon, 27 Jun 2005, Stefan Esser wrote:
> From my point of view it would have been better to have another ini directive
> like allow_url_includes that defaults to off. However under no circumstances
> allow_url_fopen can be turned back to INI_ALL. An admin has to decide if he
> allows any kind of
PHP 5 Bug Database summary - http://bugs.php.net
Num Status Summary (331 total including feature requests)
===[*General Issues]==
27372 Verified parse error loading browscap.ini at apache startup (new parser
required)
===
On Mon, 27 Jun 2005, Yasuo Ohgaki wrote:
> > I disagree. With proper filtering, or using non-user-supplied
> > information there is no problem.
>
> I don't have objection to your statement.
> It could be used safely, but there are many applications that
> had serious problems even if application
Derick Rethans wrote:
> On Mon, 27 Jun 2005, Stefan Esser wrote:
>
>
>>From my point of view it would have been better to have another ini directive
>>like allow_url_includes that defaults to off. However under no circumstances
>>allow_url_fopen can be turned back to INI_ALL. An admin has to deci
At 10:24 27/06/2005, Stefan Esser wrote:
I think most of us can agree following statement
"allow_url_fopen = ON" is dangerous and the feature is not
useful most of the times.
No, allow_url_fopen = ON is not dangerous and it is a very useful feature
when you want to fopen() a remote URL. What y
At 10:29 27/06/2005, Derick Rethans wrote:
On Mon, 27 Jun 2005, Stefan Esser wrote:
> Without a new ini directive I only see the possibility to build an
emulation
> layer:
>
> Sys: allow_url_fopen = Off -> User: ini_set("allow_url_fopen",1) fails
> Sys: allow_url_fopen = On -> User: ini_set(
On Mon, 27 Jun 2005, Rasmus Lerdorf wrote:
> Yikes, when did that happen? I have been out of Internet reach in the
> wilds of Finland for a few days, so I missed a bunch of stuff, but
> making allow_url_fopen an INI_ALL option seems like a fantastically bad
> idea. Admins should be able to contr
Jochen Hansper wrote:
The indexed array 'parameters' is expected to be:
array( {int|string} expires [, string path [, domain [, bool secure
[,bool httponly )
Why not like this?
array(
'expires' => ...,
'path' => ...,
'domain => ...,
'secure' => ...,
'httponly' => ...
);
This was the a
develop php runtime
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
IMO disable allow_url_fopen by default is a bad idea as it would break
multitudes of applications that rely on being open URLs via various PHP
functions like getimagesize(), simplexml_load_file(), etc...
I think Stefan's idea of allowing the setting to be disabled by the
script, but not enable
On Mon, 27 Jun 2005, Ilia Alshanetsky wrote:
> IMO disable allow_url_fopen by default is a bad idea as it would break
> multitudes of applications that rely on being open URLs via various PHP
> functions like getimagesize(), simplexml_load_file(), etc...
>
> I think Stefan's idea of allowing the
Hi Ilia,
I think Stefan's idea of allowing the setting to be disabled by the
script, but not enabled by it is the best. This way script writers who
know which parts of the app/library do not need the functionality can
explicitly disable it there.
My idea was a little bit different. I would l
Stefan Esser wrote:
My idea was a little bit different. I would like to allow disabling and
enabling. Of course enabling only if the vhost setting says that it was
enabled in the first place.
Would that not already be possible by calling ini_restore() ?
Ilia
--
PHP Internals - PHP Runtime De
On Mon, 27 Jun 2005, Stefan Esser wrote:
> > I think Stefan's idea of allowing the setting to be disabled by the script,
> > but not enabled by it is the best. This way script writers who know which
> > parts of the app/library do not need the functionality can explicitly
> > disable it there.
>
Would that not already be possible by calling ini_restore() ?
Well yes... I just mean the thing was INI_ALL not sooo long ago. Maybe
some script have something like this:
ini_set("allow_url_fopen", 0);
... do include stuff ..
ini_set("allow_url_fopen", 1);
such functionality was broken a
We're getting a lot of reports from Fedora Core 4 users that the shipped
PHP 5.0.4 is triggering some refcounting bug breaking some common apps;
the attached file is a repro case which triggers the segfault after
following the link.
I've traced this through and it seems that the refcount on
PS
On Mon, 27 Jun 2005 16:06:41 +0100
[EMAIL PROTECTED] (Joe Orton) wrote:
> We're getting a lot of reports from Fedora Core 4 users that the
> shipped PHP 5.0.4 is triggering some refcounting bug breaking
> some common apps; the attached file is a repro case which
> triggers the segfault after follo
On Mon, 27 Jun 2005, Pierre-Alain Joye wrote:
> You have to use .txt attachment here, everything else is removed.
He did - i saw the attachment ;-)
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
--
PHP Internals - PHP Runtime Development Mailing List
To u
You have to use .txt attachment here, everything else is removed.
Not really... I got his file.
Stefan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
It has been INI_ALL for a looong time until somebody decided to set it
to INI_SYSTEM.
Actually it was "--enable-url-fopen" for a loong time until it became
runtime configurable. It was *mistakenly* set to PHP_INI_ALL, but was
supposed to have been PHP_INI_SYSTEM. (In line with prior behavio
Derick Rethans wrote:
> On Mon, 27 Jun 2005, Yasuo Ohgaki wrote:
>
>
>>Since release_sysvsem_sem has error message while releasing acquired
>>semaphores (both PHP_4_4 and PHP_5_1), it may end up with semaphore
>>leak when error handler is used.
>>
>>The error message is useful for debugging, so t
The default build of php4ts.dll has grown from 3,421k in 5.0.4 to
4,297k in 5.1.0b2 (an increase of over 25%). Does anyone know what the
change was that had such a dramatic effect on the size of the DLL?
Michael Sisolak
[EMAIL PROTECTED]
1.6MB timezonedb.h in ext/date/lib/ would be a good guess. :)
--Jani
On Mon, 27 Jun 2005, Michael Sisolak wrote:
The default build of php4ts.dll has grown from 3,421k in 5.0.4 to
4,297k in 5.1.0b2 (an increase of over 25%). Does anyone know what the
change was that had such a dramatic
On Tue, 28 Jun 2005, Jani Taskinen wrote:
>
>1.6MB timezonedb.h in ext/date/lib/ would be a good guess. :)
And two bundled SQLite libraries (timezone db is only 200kb).
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
--
PHP Internals - PHP Runtime
Should those really be built into php4ts.dll?
"Derick Rethans" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]
> On Tue, 28 Jun 2005, Jani Taskinen wrote:
>
>>
>>1.6MB timezonedb.h in ext/date/lib/ would be a good guess. :)
>
> And two bundled SQLite libraries (timezone db
Unknown W. Brackets writes:
> Why not simply disable allow_url_fopen on your server or servers?
Why don't people do that? Obviously ... they don't.
If you have no other answer than "Maybe they don't care about
security, maybe they're stupid, maybe they're native", then may I
suggest that the pr
Ron Korving writes:
> Personally, I think include is just fine the way it is.
Google for "php security flaw". Do you think *that's* fine the way it
is?
Clearly, the fact that you can turn this behavior off suggests that
somebody has noticed that it's badly designed. Rather than say, as
some pe
Yasuo Ohgaki writes:
> 1) change allow_url_fopen to INI_ALL
> 2) disable allow_url_fopen by default
>
> I would like to see these changes in PHP 5.1 and PHP 4.4, since this
> is security related changes.
What problem are you trying to solve? Attacks against the very common
misuse of:
inc
Nicolas Bérard Nault writes:
> Correctly using the include clause is the programmer's responsability.
And yet ... I keep going back to the fact that people don't use it
correctly. It's a fact that many people use 'include' incorrectly.
If you say that the people are wrong, then you are asking p
Russell Nelson wrote:
> Yasuo Ohgaki writes:
> > 1) change allow_url_fopen to INI_ALL
> > 2) disable allow_url_fopen by default
> >
> > I would like to see these changes in PHP 5.1 and PHP 4.4, since this
> > is security related changes.
>
> What problem are you trying to solve? Attacks aga
Should it be named php4ts?
Andrey
Quoting DvDmanDT <[EMAIL PROTECTED]>:
Should those really be built into php4ts.dll?
"Derick Rethans" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]
On Tue, 28 Jun 2005, Jani Taskinen wrote:
1.6MB timezonedb.h in ext/date/lib/ would be
I agree that we need to improve the overall level of security in PHP,
but I am not sure that focusing on allow_url_fopen is very constructive.
There are far far more web sites that have these other unfiltered user
data issues than have url_fopen issues.
I agree with Rasmus. Remote URL Include
38 matches
Mail list logo
