[PHP-DEV] Re: [PHP-QA] Re: PHP-4.0.7RC1

[Zeev Suraski]

At 03:51 18-08-01, Richard Lynch wrote:
Relying on initialization by the system instead of doing it by hand is bad.

What if somebody then includes your file into something else, but has used
that variable, but their final value is usually 0, except when it's not...

Then, your code works for a while and then inexplicably breaks.

Always initialize variables.

In that example, you would break the outer code if you initialize the 
variable...  The right solution here is separation using scopes (functions 
or classes).  I think that include()'ing logic into the global scope is not 
a very good idea unless they're integrated parts of the application.

Zeev


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: PHP-4.0.7RC1

[Cynic]

At 12:23 8/17/2001, Zeev Suraski wrote the following:
-- 
At 12:00 17-08-01, Hellekin O. Wolf wrote:
At 21:15 16/08/2001 +0300, Zeev Suraski wrote:
What is the default error_reporting ? (When no value has been defined ?)

The default error reporting is E_ALL  ~E_NOTICE - or, in other words, all types of 
errors and warnings, except for notices.

Zeev

*** Will that be a difference between 4.0.7 and 4.1 ? I mean, would 4.1 take E_ALL 
as a default ?

It hasn't been decided yet, but my guess is that it won't change.  It may be a good 
idea to add it into the php.ini-recommended, though.

I vote for E_ALL as default in 4.1. NB I thought it was agreed 
that the same code will be released as 4.0.7 and 4.1.0 with the 
difference being php.ini settings. Was it a misperception on my
part?




[EMAIL PROTECTED]
-
And the eyes of them both were opened and they saw that their files
were world readable and writable, so they chmoded 600 their files.
- Book of Installation chapt 3 sec 7 


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: PHP-4.0.7RC1

[Zeev Suraski]

At 16:21 17-08-01, Cynic wrote:
I vote for E_ALL as default in 4.1. NB I thought it was agreed
that the same code will be released as 4.0.7 and 4.1.0 with the
difference being php.ini settings. Was it a misperception on my
part?

Defaults and ini settings (the binary will also reflect the new default 
php.ini settings).

The reasons I'm not sure about whether E_NOTICE should be in or not:

- The consequences of turning it on are extremely far reaching - it 
requires you to go over each and every line of your code, until the very 
last one, and check it, on the logical level (i.e., try to think about 
every possible path of execution).
- It's almost always harmless, especially after we change the default value 
of register_globals to off.

I'm very non decisive about my opinion on this one.  I know that in 1997 
when these warnings were added to the language in the first place, they 
were E_WARNING's.  Rasmus and others said that these warnings were too 
excessive, and introduced the NOTICE (or STRICT as it was called back then) 
error level, which was off by default, basically telling people it's ok to 
write code that way.  This happened about 4 years ago, at the early days of 
PHP 3.0.  Weighting the gain (it's there, but it's not overwhelming) and 
weighting the mess (it's there alright :), it very difficult to come up 
with a firm decision.

I consider E_NOTICE as a basic element of good programming 
practices.  Unlike register_globals, which simply begs for security bugs to 
occur, though, E_NOTICE is more of an application-level, code-cleanliness 
kind of suggestion.  That's why I think that adding it to the 
php.ini-recommended is a good first step.

While we're at it, I think that we should also take another recommendation 
from the advisory that brought this mess upon us - and turn URL fopens off 
by default.

Zeev


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: PHP-4.0.7RC1

[Cynic]

At 15:35 8/17/2001, Zeev Suraski wrote the following:
-- 
At 16:21 17-08-01, Cynic wrote:
I vote for E_ALL as default in 4.1. NB I thought it was agreed
that the same code will be released as 4.0.7 and 4.1.0 with the
difference being php.ini settings. Was it a misperception on my
part?

Defaults and ini settings (the binary will also reflect the new default php.ini 
settings).

The reasons I'm not sure about whether E_NOTICE should be in or not:

- The consequences of turning it on are extremely far reaching - it requires you to 
go over each and every line of your code, until the very last one, and check it, on 
the logical level (i.e., try to think about every possible path of execution).
- It's almost always harmless, especially after we change the default value of 
register_globals to off.

I'm very non decisive about my opinion on this one.  I know that in 1997 when these 
warnings were added to the language in the first place, they were E_WARNING's.  
Rasmus and others said that these warnings were too excessive, and introduced the 
NOTICE (or STRICT as it was called back then) error level, which was off by default, 
basically telling people it's ok to write code that way.  This happened about 4 years 
ago, at the early days of PHP 3.0.  Weighting the gain (it's there, but it's not 
overwhelming) and weighting the mess (it's there alright :), it very difficult to 
come up with a firm decision.

I consider E_NOTICE as a basic element of good programming practices.  Unlike 
register_globals, which simply begs for security bugs to occur, though, E_NOTICE is 
more of an application-level, code-cleanliness kind of suggestion.  That's why I 
think that adding it to the php.ini-recommended is a good first step.

I'd do this:

4.0.7:
php.ini-standard   basically today's php.ini-dist
php.ini-recommendedbasically today's php.ini-optimized
   + the proposed security related changes
   what this is exactly I don't know. perhaps
   only register_globals off

4.1.0:
php.ini-standard   php.ini-recommended as contained in 4.0.7
   + anything else you think should be there
   (it can be more strict than 4.0.7's rec.)
php.ini-compat php.ini-standard as contained in 4.0.7

And while I'm at it: can the Powers That Be consider switching the
default setting for display_startup_errors to On in either of the 
ini files? I believe (my experience indicates it) that this would
help to lower the confusion in some cases quite a bit: a message 
instead of just a 500 can change one's day.

While we're at it, I think that we should also take another recommendation from the 
advisory that brought this mess upon us - and turn URL fopens off by default.

+0




[EMAIL PROTECTED]
-
And the eyes of them both were opened and they saw that their files
were world readable and writable, so they chmoded 600 their files.
- Book of Installation chapt 3 sec 7 


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: PHP-4.0.7RC1

[Zeev Suraski]

At 17:05 17-08-01, Cynic wrote:
I'd do this:

4.0.7:
php.ini-standard   basically today's php.ini-dist
php.ini-recommendedbasically today's php.ini-optimized
+ the proposed security related changes
what this is exactly I don't know. perhaps
only register_globals off

This already exists today (except -standard is still called -dist, as 
there's no real reason to change it).  We may try to encourage people to 
read php.ini-recommended at the and of the build process, because I fear 
nobody's looking at it today.

4.1.0:
php.ini-standard   php.ini-recommended as contained in 4.0.7
+ anything else you think should be there
(it can be more strict than 4.0.7's rec.)
php.ini-compat php.ini-standard as contained in 4.0.7

I'm not sure that we can just move to do -recommended version, 4.1.0 or 
not.  The nature of recommendations is that some people accept them, and 
some do not :)  None of the things in the php.ini-recommended file is a 
clear-cut must-have, and some people will prefer doing without them.  We'll 
have to think about each change separately.

Remember that we only use the version change to catch people's 
attention.  It doesn't mean that we can suddenly make PHP much more 
'hostile' :)

And while I'm at it: can the Powers That Be consider switching the
default setting for display_startup_errors to On in either of the
ini files? I believe (my experience indicates it) that this would
help to lower the confusion in some cases quite a bit: a message
instead of just a 500 can change one's day.

There's a good reason for this default setting.  A clear message will not 
only change your day, but also the guy who's trying to hack your site's day 
:)  For example, with display_startup_errors set to on, a request can be 
easily made that will expose the full path of any scripts on your site.
It may make good sense to set it on in the -recommended version, as it's 
safe in conjunction with display_errors=0 and log_errors=1.

Zeev


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: PHP-4.0.7RC1

[Cynic]

At 16:13 8/17/2001, Zeev Suraski wrote the following:
-- 
At 17:05 17-08-01, Cynic wrote:
I'd do this:

4.0.7:
php.ini-standard   basically today's php.ini-dist
php.ini-recommendedbasically today's php.ini-optimized
   + the proposed security related changes
   what this is exactly I don't know. perhaps
   only register_globals off

This already exists today (except -standard is still called -dist, as there's no real 
reason to change it).  We may try to encourage people to read php.ini-recommended at 
the and of the build process, because I fear nobody's looking at it today.

4.1.0:
php.ini-standard   php.ini-recommended as contained in 4.0.7
   + anything else you think should be there
   (it can be more strict than 4.0.7's rec.)
php.ini-compat php.ini-standard as contained in 4.0.7

I'm not sure that we can just move to do -recommended version, 4.1.0 or not.  The 
nature of recommendations is that some people accept them, and some do not :)  None 
of the things in the php.ini-recommended file is a clear-cut must-have, and some 
people will prefer doing without them.  We'll have to think about each change 
separately.

Remember that we only use the version change to catch people's attention.  It doesn't 
mean that we can suddenly make PHP much more 'hostile' :)

But it's a nice opportunity to do so. BTW, I consider a site hacked 
thanks to default settings that promote poor coding more hostile
in the end. :)

And while I'm at it: can the Powers That Be consider switching the
default setting for display_startup_errors to On in either of the
ini files? I believe (my experience indicates it) that this would
help to lower the confusion in some cases quite a bit: a message
instead of just a 500 can change one's day.

There's a good reason for this default setting.  A clear message will not only change 
your day, but also the guy who's trying to hack your site's day :)  For example, with 
display_startup_errors set to on, a request can be easily made that will expose the 
full path of any scripts on your site.
It may make good sense to set it on in the -recommended version, as it's safe in 
conjunction with display_errors=0 and log_errors=1.

This doesn't hold water. display_errors is on in php.ini-dist anyways,
so what do you gain by display_startup_errors off? NB you can use 
custom error handler that won't display full physical paths, so WTF?
BTW, what is the possibility of introducing new functionality to the 
default error handler, where the file paths aren't physical paths by 
default, but URIs? I. e. with DOCUMENT_ROOT in /var/www/, instead of 
E_WARNING: blabla in /var/www/foo/bar.php on line xxx 
display
E_WARNING: blabla in /foo/bar.php on line xxx 
??

(There are some issues with this I can foresee even as I type this, 
but those could be hopefully figured out.)

And provide display_full_path_in_errors ini setting, or sumthin.


BTW, Zeev, could you please break your lines somewhere reasonable? 
It's quite unpleasant to read those loong lines. :) THX.




[EMAIL PROTECTED]
-
And the eyes of them both were opened and they saw that their files
were world readable and writable, so they chmoded 600 their files.
- Book of Installation chapt 3 sec 7 


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: PHP-4.0.7RC1

[Hellekin O. Wolf]

At 17:13 17/08/2001 +0300, Zeev Suraski wrote:
At 17:05 17-08-01, Cynic wrote:
I'd do this:

4.0.7:
php.ini-standard   basically today's php.ini-dist
php.ini-recommendedbasically today's php.ini-optimized
+ the proposed security related changes
what this is exactly I don't know. perhaps
only register_globals off

This already exists today (except -standard is still called -dist, as 
there's no real reason to change it).  We may try to encourage people to 
read php.ini-recommended at the and of the build process, because I fear 
nobody's looking at it today.

*** That's pretty clear.
Maybe we could make a setup script that would write the php.ini for the 
user depending on the --config_file_path value ?
It would propose an automatic setup (either -dist or -recommended) or a 
manual setup (yes|no,1|0 style).
In we I don't count myself as I know Perl almost like a (real) camel.

4.1.0:
php.ini-standard   php.ini-recommended as contained in 4.0.7
+ anything else you think should be there
(it can be more strict than 4.0.7's rec.)
php.ini-compat php.ini-standard as contained in 4.0.7

I'm not sure that we can just move to do -recommended version, 4.1.0 or 
not.  The nature of recommendations is that some people accept them, and 
some do not :)  None of the things in the php.ini-recommended file is a 
clear-cut must-have, and some people will prefer doing without 
them.  We'll have to think about each change separately.

Remember that we only use the version change to catch people's 
attention.  It doesn't mean that we can suddenly make PHP much more 
'hostile' :)

*** OTOH, maybe PEAR people would like to see some comfortable defaults ?

And while I'm at it: can the Powers That Be consider switching the
default setting for display_startup_errors to On in either of the
ini files? I believe (my experience indicates it) that this would
help to lower the confusion in some cases quite a bit: a message
instead of just a 500 can change one's day.

There's a good reason for this default setting.  A clear message will not 
only change your day, but also the guy who's trying to hack your site's 
day :)  For example, with display_startup_errors set to on, a request can 
be easily made that will expose the full path of any scripts on your site.
It may make good sense to set it on in the -recommended version, as it's 
safe in conjunction with display_errors=0 and log_errors=1.

Zeev
*** I understood that 4.0.7 / 4.1.0 would be a question of what we want next.

If E_ALL brings better code, why not encourage that ?
Democracy is good as long as it's evolving. If we encourage a default lax 
behavior, lax coders we'll have. If we encourage tighter programming, even 
the novice can cope with it and learn faster, and make less mistakes, etc.
Is that too optimistic ? Or am I forgetting the existing code base ?

I think that as $HTTP_*_VARS disappear, lots of people will have to change 
that (Search/Replace + delete the corresponding global calls) anyway in 
order to use the new $_* arrays in future versions.
It's probably better to bother people once for good instead of once every 
version. The purpose of 4.0.* vs .4.1.* should be clear for all : it's a 
new step and you have to make it.

RFC

hellekin


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: PHP-4.0.7RC1

[Zeev Suraski]

At 17:43 17-08-01, Hellekin O. Wolf wrote:
*** I understood that 4.0.7 / 4.1.0 would be a question of what we want next.

4.1.0 will.  We're not changing any defaults in 4.0.7...

If E_ALL brings better code, why not encourage that ?
Democracy is good as long as it's evolving. If we encourage a default lax 
behavior, lax coders we'll have. If we encourage tighter programming, even 
the novice can cope with it and learn faster, and make less mistakes, etc.
Is that too optimistic ? Or am I forgetting the existing code base ?

I think it's a bit too optimistic, not to mention the existing code base :)

I think that as $HTTP_*_VARS disappear, lots of people will have to change 
that (Search/Replace + delete the corresponding global calls) anyway in 
order to use the new $_* arrays in future versions.

There's a fundamental difference - setting E_NOTICE on means you have to 
audit *all* of your code, and in some cases, think about every possible 
execution path, just to see if you have a problem.  While the HTTP_*_VARS 
is an easy SR issue, and even setting register_globals off affects only 
the form-interface part of the application and is usually also an issue of 
SR (slower, but still SR), there's no way to fix all notices in a quick 
way.  Even if you find the problems (which is very time consuming), fixing 
them can't be done using SR, and it sometimes even requires changes to the 
logic.

It's not that While we're at it type of action, it has considerable 
additional implications.

It's probably better to bother people once for good instead of once every 
version. The purpose of 4.0.* vs .4.1.* should be clear for all : it's a 
new step and you have to make it.

First off, nobody *has* to do anything.  They can always use an old 
version, or if we screw up too badly, switch to something else (I think the 
register_globals thing alone will take at least a year to catch, especially 
considering we're not eliminating the ability to turn it on).
We're walking on a fine line here, between keeping PHP's ease of use and 
cleanliness.  PHP is *definitely* not the cleanest language around, and 
it's not meant to be, either.  That's why not every action that would 
result in a 'cleaner' language is automatically applied.

Zeev


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: PHP-4.0.7RC1

[Stanislav Malyshev]

ZS I consider E_NOTICE as a basic element of good programming
ZS practices.  Unlike register_globals, which simply begs for
ZS security bugs to

Actually, I fail to see why it is so. Let's see two code snippets:

if($arr['foo']) { ... do something ... }
if(isset($arr['foo'])  $arr['foo']!=false) { ... do something ... }

Both have the same function, but the first generates E_NOTICE. Why the
first is bad programming practice? How many PHP users would really prefer
the second over the first?

ZS kind of suggestion.  That's why I think that adding it to the
ZS php.ini-recommended is a good first step.

However, it would make average PHP code to output tens of warnig, which
would be annoying and would hardly be useful in many cases.

ZS While we're at it, I think that we should also take another
ZS recommendation from the advisory that brought this mess upon us
ZS - and turn URL fopens off by default.

Well, generally I personally would even go further and make two functions
- one for file-only fopen (about 90% of fopen usage?) and another which
would open everything and the kitchen://sink. Or make some switch, etc. -
configuration option doesn't seem to me fit here, it's not per-server but
per-script property if you want URL fopens or not.

-- 
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: PHP-4.0.7RC1

[Cynic]

At 18:16 8/17/2001, Stanislav Malyshev wrote the following:
-- 
ZS I consider E_NOTICE as a basic element of good programming
ZS practices.  Unlike register_globals, which simply begs for
ZS security bugs to

Actually, I fail to see why it is so. Let's see two code snippets:

if($arr['foo']) { ... do something ... }
if(isset($arr['foo'])  $arr['foo']!=false) { ... do something ... }

if('foo' == $x){
  $secure = true;
}
...
if($secure){
  # do sumthing that needs authentication
}

This will happily run in E_ALL ~ E_NOTICE whether $x == 'foo' or not.
Attacker can then inject $secure in the query string, and it'll apply
whether or not $x == 'foo'. This will be caught with error_reporting
E_ALL.

Both have the same function, but the first generates E_NOTICE. Why the
first is bad programming practice? How many PHP users would really prefer
the second over the first?

ZS kind of suggestion.  That's why I think that adding it to the
ZS php.ini-recommended is a good first step.

However, it would make average PHP code to output tens of warnig, which
would be annoying and would hardly be useful in many cases.

Yes, average PHP code is full of security or other holes.




[EMAIL PROTECTED]
-
And the eyes of them both were opened and they saw that their files
were world readable and writable, so they chmoded 600 their files.
- Book of Installation chapt 3 sec 7 


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: PHP-4.0.7RC1

[Stanislav Malyshev]

C if('foo' == $x){
C   $secure = true;
C }
C ...
C if($secure){
C   # do sumthing that needs authentication
C }
C
C This will happily run in E_ALL ~ E_NOTICE whether $x == 'foo' or not.
C Attacker can then inject $secure in the query string, and it'll apply
C whether or not $x == 'foo'. This will be caught with error_reporting
C E_ALL.

That's entirely different issue, having nothing to do with notices, but
with register_globals and mixing internal and user-supplied variables. The
fact that E_NOTICE may in some situation help you to find it is lucky (or,
on the second thought, unlucky - it may as well not happen, and you are
toast with all your belief in notices) coincidence, nothing more.

C Yes, average PHP code is full of security or other holes.

That's overbroad statement which is just wrong. I can show you a lot of
scripts generating a real lot of notices, but having no security hole.

Also, note that fixing notice in the above code in the obvious way -
changing simple if() to isset and stuff - will shut up your precious
notice mechanism, while leaving the hole wide open. Is that what you want?

-- 
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: PHP-4.0.7RC1

[Zeev Suraski]

At 19:16 17-08-01, Stanislav Malyshev wrote:
ZS I consider E_NOTICE as a basic element of good programming
ZS practices.  Unlike register_globals, which simply begs for
ZS security bugs to

Actually, I fail to see why it is so. Let's see two code snippets:

if($arr['foo']) { ... do something ... }
if(isset($arr['foo'])  $arr['foo']!=false) { ... do something ... }

Both have the same function, but the first generates E_NOTICE. Why the
first is bad programming practice? How many PHP users would really prefer
the second over the first?

This is one case in which there's no added value to E_NOTICE - in your 
example, you explicitly don't care whether the variable exists or 
not.  There are many cases in which there is an added value in 
E_NOTICE.  For example:

for ($i=0; $i100; $i++) {
 $sum += sth()
}

print The total some is $total;

True, a dumb programming error (it can get more complex), but an E_NOTICE 
would have caught in a second.  I think that in the post register_globals 
era it'll usually not help uncover security bugs, but it improves code 
cleanliness.

ZS kind of suggestion.  That's why I think that adding it to the
ZS php.ini-recommended is a good first step.

However, it would make average PHP code to output tens of warnig, which
would be annoying and would hardly be useful in many cases.

I agree.  I'm saying that it's a difficult call.

ZS While we're at it, I think that we should also take another
ZS recommendation from the advisory that brought this mess upon us
ZS - and turn URL fopens off by default.

Well, generally I personally would even go further and make two functions
- one for file-only fopen (about 90% of fopen usage?) and another which
would open everything and the kitchen://sink. Or make some switch, etc. -
configuration option doesn't seem to me fit here, it's not per-server but
per-script property if you want URL fopens or not.

You can set any INI entries using ini_set() for a particular script.  I 
think adding new functions is messy - too many functions in PHP support 
opening URLs (because they're built on top of fopen-wrappers).

Zeev


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: PHP-4.0.7RC1

[Hellekin O. Wolf]

At 19:16 17/08/2001 +0300, Stanislav Malyshev wrote:
ZS While we're at it, I think that we should also take another
ZS recommendation from the advisory that brought this mess upon us
ZS - and turn URL fopens off by default.

Well, generally I personally would even go further and make two functions
- one for file-only fopen (about 90% of fopen usage?) and another which
would open everything and the kitchen://sink. Or make some switch, etc. -
configuration option doesn't seem to me fit here, it's not per-server but
per-script property if you want URL fopens or not.

*** Consider a mutli-user environment, like an ISP, where many users can 
script on the same server.
In that case, we need a system-wide configuration flag.
However, I agree with you that some cases may require having 
allow_url_fopen On while preventing most of the others from using it.
I think that case is not depending on PHP but rather on a correctly 
implemented httpd server.

hellekin


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: PHP-4.0.7RC1

[Zeev Suraski]

At 19:35 17-08-01, Cynic wrote:
This will happily run in E_ALL ~ E_NOTICE whether $x == 'foo' or not.
Attacker can then inject $secure in the query string, and it'll apply
whether or not $x == 'foo'. This will be caught with error_reporting
E_ALL.

That's just a specific case of the register_globals problem.  We're already 
phasing register_globals out...  In the post register_globals era, the 
likelihood that E_NOTICE's will be hiding a security bug is much, much 
lower.  However, there are quite a few other situations in which E_NOTICE's 
are emitted, which are perfectly ok.  It has to do with coding style, not 
security.

Yes, average PHP code is full of security or other holes.

E_NOTICE's only sometimes imply a security hole or a bug.  Very often, they 
imply absolutely nothing.

Zeev


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: PHP-4.0.7RC1

[Stanislav Malyshev]

ZS This is one case in which there's no added value to E_NOTICE - in your
ZS example, you explicitly don't care whether the variable exists or
ZS not.  There are many cases in which there is an added value in
ZS E_NOTICE.  For example:

Agreed. But if we enable it by default, we may actually do a disservice
for the user - because the useful cases are lost in the swarm of the unuseful
ones. If we want to make them useful, some mechanism of weeding out the
more useful and burying the rest should be established. Otherwise user
just learns to ignore them (as people learned to ignore windows messages
and press OK at whatever thing happens).

ZS You can set any INI entries using ini_set() for a particular script.  I

I know. That's shaving with an axe - I can do it, but that's wrong thing
to do. User should not be encouraged to fiddle with ini_set unless it is
absolutely necessary.

ZS think adding new functions is messy - too many functions in PHP support
ZS opening URLs (because they're built on top of fopen-wrappers).

Well, maybe there is some middle-ground solution. I just see encouraging
of ini_set to be wrong. There should be a better way to do it.

-- 
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: PHP-4.0.7RC1

[Zeev Suraski]

At 19:54 17-08-01, Stanislav Malyshev wrote:
I know. That's shaving with an axe - I can do it, but that's wrong thing
to do. User should not be encouraged to fiddle with ini_set unless it is
absolutely necessary.

I disagree.  ini_set() is kinda like inspector Gadget's hat, you can find a 
shaver there if you want to.
We can have a wrapper function, url_fopens_enable() which would in turn 
call ini_set(), but generally I think it's a bad idea to add these 
redundant functions.

Zeev


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: PHP-4.0.7RC1

[Richard Lynch]

Relying on initialization by the system instead of doing it by hand is bad.

What if somebody then includes your file into something else, but has used
that variable, but their final value is usually 0, except when it's not...

Then, your code works for a while and then inexplicably breaks.

Always initialize variables.

--
WARNING [EMAIL PROTECTED] address is an endangered species -- Use
[EMAIL PROTECTED]
Wanna help me out?  Like Music?  Buy a CD: http://l-i-e.com/artists.htm
Volunteer a little time: http://chatmusic.com/volunteer.htm
- Original Message -
From: Stanislav Malyshev [EMAIL PROTECTED]
To: Cynic [EMAIL PROTECTED]
Cc: Zeev Suraski [EMAIL PROTECTED]; [EMAIL PROTECTED]; PHP Development
[EMAIL PROTECTED]
Sent: Friday, August 17, 2001 11:33 AM
Subject: Re: [PHP-QA] Re: PHP-4.0.7RC1


 C if('foo' == $x){
 C   $secure = true;
 C }
 C ...
 C if($secure){
 C   # do sumthing that needs authentication
 C }
 C
 C This will happily run in E_ALL ~ E_NOTICE whether $x == 'foo' or not.
 C Attacker can then inject $secure in the query string, and it'll apply
 C whether or not $x == 'foo'. This will be caught with error_reporting
 C E_ALL.

 That's entirely different issue, having nothing to do with notices, but
 with register_globals and mixing internal and user-supplied variables. The
 fact that E_NOTICE may in some situation help you to find it is lucky (or,
 on the second thought, unlucky - it may as well not happen, and you are
 toast with all your belief in notices) coincidence, nothing more.

 C Yes, average PHP code is full of security or other holes.

 That's overbroad statement which is just wrong. I can show you a lot of
 scripts generating a real lot of notices, but having no security hole.

 Also, note that fixing notice in the above code in the obvious way -
 changing simple if() to isset and stuff - will shut up your precious
 notice mechanism, while leaving the hole wide open. Is that what you want?

 --
 Stanislav Malyshev, Zend Products Engineer
 [EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115



 --
 PHP Quality Assurance Mailing List http://www.php.net/
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]