Just my 2 cents. Thoughts?
Just throwing this out there... I don't even know if this is technically feasible, but is an attempt to bridge concerns of the two parties, since both of them have a point. I think it's clear that the end goals of the security team are: * Don't let the bad guys know about security bugs before the good guys. * Coordinate security releases on predictable schedules so that site admins don't need to carry a beeper. * Ensure all security-related problems are dealt with in the proper way: accompanying SAs, etc. And the concerns of some of the developers in this thread are: * I want to use the same process to fix these types of bugs that I do any other types of bugs. * I have no way to test my module to ensure that it works with the security patch applied. * I know my module better than the security team does. So let's try this: The Security Team sets up a cvs-security.drupal.org. All security members are given checkout/commit access to it, and no one else (by default). There are two directories: drupal/ : for core (constantly mirrored) modules/ : for contributed modules Additionally, the node_access module @ security.drupal.org is tweaked so that it can allow access to specific issues for individual users. Workflow is: 1. Developer discovers security hole in their module. 2. Developer notifies security@drupal.org. 3. Security team takes a copy of the currently vulnerable code and checks it into cvs-security.drupal.org at modules/foobar. Creates a CVS account for developer and gives them access to their module's directory only. 4. Security team creates a user for them at security.drupal.org, and an issue that only the developer and the rest of the security team have access to, in order to act as the central place to test/discuss patches to fix the issue. 5. Developer and security team use the normal contributed workflow to get the patch created, reviewed, applied, and tested. 6. Once fix is deemed acceptable, the normal SA process ensues. This approach brings several benefits: * Anonymous users (including blackhats) can't see the security-related commits flinging back and forth, nor read the discussion leading up to the fixes. * The security team can work in a transparent way, and increase education/mentorship of developers, while not giving blackhats any hints about what's going on. * Developers can use the same processes that they're familiar with. * Developers can test exactly what code will be downloaded by their end users. No nasty surprises like Drupal 5.4->5.5. We can even increase the number of security team members to include those who /just/ do QA testing on a release before it's pushed out. * Releases can continue to be pushed out twice a month on predictable, regular intervals, making site admin lives much easier. Seems to satisfy all concerns. Thoughts? -Angie