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 fo
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.
Alway
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
shav
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 actual
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_
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 tw
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 so
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
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 t
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']!=
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
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
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
>>
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
>>
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. pe
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 bei
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
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
18 matches
Mail list logo
