Would you prefer to use something that was designed to be secure or something that had security applied to it as an afterthought? As time goes by, if something is designed to be secure then the number of bugs that impact security should diminish with time because they are flaws in the implementation (or design.) New features are designed to fit within the existing security model. If security is just added on, every time a new feature is added there is the chance of a security flaw because the security boundary needs to be extended to suit this new feature and thus the chances of a bug leading to a security issue are higher. In addition, bug fixes can also introduce security holes through unintended interaction consequences. Since this thread started, how many java related bugs have been posted to bugtraq vs how many for php? In keeping with any of the ratios mentioned? I think not. You wanted to compare "bug types" - I'd prefer to see a small number (and your "100" was way too large to be realistic) of bugs in the framework than lots of "in use" bugs. Why? Because it tells me that the framework makes it very hard for the average programmer to make a mistake that has security implications. It is time to throw php out and start over with something new. Something that has security as part of its design. Something that learns from all of the security mistakes made with php. Something that is written with the actual audience that will use it (security ignorant) in mind, making it easy to develop dynamic content but using constructs that are aware of how hostile web interaction can be and that make it quite difficult to create security flaws. Darren
