Re: Fwd: cvs commit: httpd-test/perl-framework/t/htdocs/security CAN-2004-0958.php
Cliff Woolley wrote: On Tue, 23 Nov 2004, Joe Orton wrote: Discussion of whether or not it's useful to have PHP tests in httpd-test can take place on test-dev@, please send your comments there and I'll follow up. I actually think it's useful to have php tests in our suite, because having a large number of tests for a module as big as php helps to flush out bugs in httpd (and maybe apr). That would be even more the case if php's sapi module for httpd 2.x that worked as a filter were in a reasonable state... now that TestRunPHP and TestConfigPHP are complete, I was considering moving the existing php tests over to this new framework. the advantage is that each individual test would get an ok marker at a granular level, rather than a simple ok that represented, say, 5 tests together in a lump. how does this sound to everyone? I'd probably get to it sometime over the next two weeks, and I'd post a major diff before going forward. --Geoff
Re: Fwd: cvs commit: httpd-test/perl-framework/t/htdocs/security CAN-2004-0958.php
At 12:25 PM 11/23/2004, Cliff Woolley wrote: On Tue, 23 Nov 2004, Joe Orton wrote: Discussion of whether or not it's useful to have PHP tests in httpd-test can take place on test-dev@, please send your comments there and I'll follow up. I actually think it's useful to have php tests in our suite, because having a large number of tests for a module as big as php helps to flush out bugs in httpd (and maybe apr). That would be even more the case if php's sapi module for httpd 2.x that worked as a filter were in a reasonable state... I totally agree that regression testing is terrific. We gain alot knowing when our patches might break php. What I questioned was why we were doing the security validation of PHP when it's outside the scope of httpd, or isn't due to some interaction with httpd. I also questioned shoving scary security/CAN-2004-.t failures at our users. FIRST this should never have been in security/ - it should have been a php/ test. Again, this is not our security incident within httpd. Second, whenever we fail any CAN-2004-.t we must direct the user to some patch where they can remedy the situation. I'm sort of laughing that I spent 4 hours yesterday researching two vulns that many other engineers had spent 4 hours researching. The laughable thing - show me on www.php.net where they call out any patches for 4.3.x to these two incidents? It's akin to screaming FIRE in a crowded theater, when the doors are locked. Open up the doors first, then scream. Oh, just an aside, answering upgrade n-1.x to the latest n.0 release is no answer to a security incident. Didn't we just listen to a preso in Vegas decrying how 5.0 isn't 4.3? Bill
Re: Fwd: cvs commit: httpd-test/perl-framework/t/htdocs/security CAN-2004-0958.php
On Tue, Nov 23, 2004 at 12:55:16PM -0600, William Rowe wrote: What I questioned was why we were doing the security validation of PHP when it's outside the scope of httpd, or isn't due to some interaction with httpd. This is true for most of the functional tests of PHP in t/php/ which Covalent donated. I don't necessarily disagree, but I do I find it useful. Possibly these tests could go in the PHP test suite as well, I'm not sure. If that's your itch... I also questioned shoving scary security/CAN-2004-.t failures at our users. FIRST this should never have been in security/ - it should have been a php/ test. Again, this is not our security incident within httpd. I don't really care either way, smells like a freshly painted bikeshed to me ;) Second, whenever we fail any CAN-2004-.t we must direct the user to some patch where they can remedy the situation. I'm sort of laughing that I spent 4 hours yesterday researching two vulns that many other engineers had spent 4 hours researching. The laughable thing - show me on www.php.net where they call out any patches for 4.3.x to these two incidents? They don't, it was fixed silently, I mailed them about that but they didn't seem inclined to do anything about it. If you want to follow up on that some more, great, but ranting about it here won't make much difference. joe
