When Security Collides With Engineering (Responsible Disclosure Redux)
Stefan Esser announced earlier this week that he was retiring from firstname.lastname@example.org citing irreconcilable differences with the PHP group on how to respond to security issues within PHP.
Of particular interest is that he will be making changes to how he handles security advisories for PHP (emphasis mine):
For the ordinary PHP user this means that I will no longer hide the slow response time to security holes in my advisories. It will also mean that some of my advisories will come without patches available, because the PHP Security Response Team refused to fix them for months. It will also mean that there will be a lot more advisories about security holes in PHP.
Since Stefan has locked out commenting his post, I’ll ask here:
Stefan, are you planning on providing workarounds for the advisories that don’t yet have patches? How are you planning on balancing the need for users to know versus broader exposure of a weakness? While I fully support your desire for full disclosure, I’m curious, what is too long? Where do you draw the line now that you’ve stepped further away from the project?
[Update: And more questions after talking to Adam. Why is PHP unable to unwilling to do security to Stefan’s standards? I’d love to hear both sides of this story…
Also what does this mean for PHP users? How bad off are they anyways?]
[Image is from Stefan’s Suhosin Hardened PHP Project.]