[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 
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 
> 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 
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 
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 
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 
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 
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; $i<100; $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 
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 
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 
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 
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 S&R issue, and even setting register_globals off affects only 
the form-interface part of the application and is usually also an issue of 
S&R (slower, but still S&R), 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 S&R, 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 
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, Cynic wrote:
>This doesn't hold water. display_errors is on in php.ini-dist anyways,
>so what do you gain by display_startup_errors off?

Quite a lot.  Even if your code is rock solid, and has no warnings, errors, 
or notices whatsoever - or if you have error_reporting(0) at the top of it 
- it's still possible to make PHP emit startup errors at will.  That's 
exactly their meaning - errors that can occur due to a bogus request or 
during the request initialization, as opposed to a bug in the script.

>  NB you can use
>custom error handler that won't display full physical paths, so WTF?

Nope, you can't.  Startup errors occur before you can call custom handlers, 
before you can even declare them.  Beside, remember, you're talking about 
the default setting here.  Most people will never know what this option 
means, or what are its implications, or both, and definitely wouldn't be 
bothered to consider the ways to work around it :)

>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"
>??

This should be done at the user level.  There's no reason to do it in the C 
level, which is much more complex.

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

Hrm, which Email client today doesn't do word wrapping??

Zeev


-- 
PHP Development Mailing List 
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 
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 
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 
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 
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 
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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]