[development] Think there's a security problem in your module? Here's what to do.

[Angela Byron]

> 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 at 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