Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi
At 20:50 21/3/2001, Sascha Schumann wrote: On Wed, 21 Mar 2001, Andi Gutmans wrote: A couple of these were buffer overflows IIRC which were security issues. Remember the group@ emails about those? Fixes against format-string attacks and for file-upload issues went into 4.0.3. Or what are you referring to? The Apache module issue was a security problem. A fairly major one, too. 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]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi
The Apache module issue was a security problem. A fairly major one, too. Yes, that is why I mentioned 4.0.4pl1 as an exception in an earlier email. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- 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]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi
But I referred to 4.0.3pl1 :) At 21:23 21/3/2001, Sascha Schumann wrote: The Apache module issue was a security problem. A fairly major one, too. Yes, that is why I mentioned 4.0.4pl1 as an exception in an earlier email. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- 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]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi
At 21:25 21/3/2001, Sascha Schumann wrote: On Wed, 21 Mar 2001, Andi Gutmans wrote: Why do we need to have an interrogation. Relax, it's not such a big deal. I'm completely relaxed. I just dislike twisting history. Sascha, As Cynic said, it's really a good idea to stop the flame wars. Being cynical (nice coincidence) doesn't help, because it draws cynical remarks from the other side (as you could see). Let's just stop. The argument diverted to unrelated issues anyway. 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]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi
Though I am still considered new to this group, I thought I would put in my two cents. Are we considering fastcgi module stable? We currently release EXPERIMENTAL modules as part of the distribution. If fastcgi is considered EXPERIMENTAL, then I don't see why the module itself could not be included in the RC branch. The only piece that really has to be checked is config.m4, and in this scenario there doesn't appear to be problems(efficient or not). As long as the withval test is valid, and the module is not enabled by default it really shouldn't affect php as a whole. I believe that this is a fine exception to the rule. However, if fastcgi is being labled stable, then, IMHO, I believe it should wait for thorough testing, and the next freeze. I think that Sascha, and Jani have concerns with this being the first domino in a series of continually growing exceptions to the release process. An RP ruleset is one of those things that is often considered "Holy",and shouldn't have reoccuring exceptions. Zeev has expressed valid points about the functionality being important and shouldn't wait. Which, if there is big need for it, why can't there be a compromise? Perhaps everyone should consider altering the RP ruleset, to include an exception about adding new modules. If the exception policy was in place here are some questions of thought: What would be necessary to make it safe to php in a whole? What should the requirements be to allow this to happen ( ex. a lot of user demand, replaces something considered unstable) ? Should this require any re-testing? Should this require x amount of RCs to follow and how many? Should there be a vote on whether or not to allow the module in? Is this module something that should first be released as an add-on? I honestly agree with both positions on this one, and I think good can come from both of them : ) -Jason - Original Message - From: "Zeev Suraski" [EMAIL PROTECTED] To: "Sascha Schumann" [EMAIL PROTECTED] Cc: "PHP Developers Mailing List" [EMAIL PROTECTED]; "PHP Quality Assurance Team Mailing List" [EMAIL PROTECTED] Sent: Wednesday, March 21, 2001 1:33 PM Subject: Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi But I referred to 4.0.3pl1 :) At 21:23 21/3/2001, Sascha Schumann wrote: The Apache module issue was a security problem. A fairly major one, too. Yes, that is why I mentioned 4.0.4pl1 as an exception in an earlier email. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- 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 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]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi
It's definitely considered experimental. Zeev At 22:19 21/3/2001, Jason Greene wrote: Though I am still considered new to this group, I thought I would put in my two cents. Are we considering fastcgi module stable? We currently release EXPERIMENTAL modules as part of the distribution. If fastcgi is considered EXPERIMENTAL, then I don't see why the module itself could not be included in the RC branch. The only piece that really has to be checked is config.m4, and in this scenario there doesn't appear to be problems(efficient or not). As long as the withval test is valid, and the module is not enabled by default it really shouldn't affect php as a whole. I believe that this is a fine exception to the rule. However, if fastcgi is being labled stable, then, IMHO, I believe it should wait for thorough testing, and the next freeze. I think that Sascha, and Jani have concerns with this being the first domino in a series of continually growing exceptions to the release process. An RP ruleset is one of those things that is often considered "Holy",and shouldn't have reoccuring exceptions. Zeev has expressed valid points about the functionality being important and shouldn't wait. Which, if there is big need for it, why can't there be a compromise? Perhaps everyone should consider altering the RP ruleset, to include an exception about adding new modules. If the exception policy was in place here are some questions of thought: What would be necessary to make it safe to php in a whole? What should the requirements be to allow this to happen ( ex. a lot of user demand, replaces something considered unstable) ? Should this require any re-testing? Should this require x amount of RCs to follow and how many? Should there be a vote on whether or not to allow the module in? Is this module something that should first be released as an add-on? I honestly agree with both positions on this one, and I think good can come from both of them : ) -Jason - Original Message - From: "Zeev Suraski" [EMAIL PROTECTED] To: "Sascha Schumann" [EMAIL PROTECTED] Cc: "PHP Developers Mailing List" [EMAIL PROTECTED]; "PHP Quality Assurance Team Mailing List" [EMAIL PROTECTED] Sent: Wednesday, March 21, 2001 1:33 PM Subject: Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi But I referred to 4.0.3pl1 :) At 21:23 21/3/2001, Sascha Schumann wrote: The Apache module issue was a security problem. A fairly major one, too. Yes, that is why I mentioned 4.0.4pl1 as an exception in an earlier email. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- 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] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- 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]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi
At 22:19 21/3/2001, Jason Greene wrote: If the exception policy was in place here are some questions of thought: What would be necessary to make it safe to php in a whole? I'd say that a module that has no effect on building PHP is fine to add as an experimental module. The only reason I believe we need at least one RC afterwards, is to ensure that trivial problems weren't introduced (mostly, a broken build). What should the requirements be to allow this to happen ( ex. a lot of user demand, replaces something considered unstable) ? I think that these are the same requirements for any other module that we decide to admit to the tree. Since it's not a big deal, if it belongs in the PHP 4.0 tree, then it's ok to add it whilst in RC's. Should this require any re-testing? Should this require x amount of RCs to follow and how many? IMHO, one more RC. Should there be a vote on whether or not to allow the module in? We don't have a body with 'jurisdiction' other than the PHP Group, so I'd say no; Whatever loose guidelines we use today to admit new modules can apply here as well. Is this module something that should first be released as an add-on? I honestly agree with both positions on this one, and I think good can come from both of them : ) I think that by saying you agree with both positions you attribute to me things that I didn't say :) I'm all in favour of a stable release process. I'm not in favour in considering the release process guidelines as 'holy', and if I or anybody else thinks they can be improved, the right step would be to raise it for discussion. As I said to Hartmut, the minute bureaucracy becomes sacred, you know you're doing something wrong. I considered the fact that the release process did not account for new experimental modules a limitation of the release process. Even the US constitution required a few amendments before they got it right :) Zeev -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- 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]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi
At 16:38 21/3/2001, Thies C. Arntzen wrote: i fully agree to sascha. plus i see no real reason to include a new module once we are in "release-process". new modules are by default not "producition-stable" so why hurry to include them in a "official-release"? For wide exposure. SAPI modules will not get very far without it. the no. 1 (and maybe only goal) for a release should be stability and well tested functionality IMHO. Stability is irrelevant with new modules - they did not exist before, so they can't be less stable, and figuring whether their addition breaks PHP is trivial, and would be discovered in a second if they manage to do that somehow. New modules are no different from any of the unstable modules that exist in PHP, and there are plenty of them. 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]
