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

[Derek Wright]

On Jan 17, 2008, at 7:41 PM, Angela Byron wrote:

> I don't even know if this is technically feasible

Completely.

> The Security Team sets up a cvs-security.drupal.org.

<bikeshed>
cvs.security.drupal.org?
</bikeshed>

> Additionally, the node_access module @ security.drupal.org is  
> tweaked so that it can allow access to specific issues for  
> individual users.

project_issue can do this itself. ;) 'access own issues'.

> 1. Developer discovers security hole in their module.
> 2. Developer notifies security at drupal.org.

or creates an issue @ 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.

Easy.  We already have separate projects on sec.d.o for all modules  
that have had security issues.  Could use the same CVS access for cvs- 
sec.d.o -> sec.d.o as we do with cvs.d.o -> d.o.  In fact, we could  
automate that each cvs account holder on d.o has an account in a  
separate CVS repo on cvs.sec.d.o.  The CVS access tab on project  
nodes would be used to generate accounts in the CVSROOT/passwd files  
for each private repo.

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

Trivial.  We could ensure that all users with CVS accounts on d.o  
also have limited access user accounts on sec.d.o that can at least  
submit issues for their own projects and access to their own projects  
CVS repos.  We could have an automated solution to keep the project  
nodes in sync between the 2 sites.

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

Sounds great.

> Seems to satisfy all concerns. Thoughts?

I love it!  All the benefits you list are true, and there are others...

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


Additionally, we could:

* Setup the automated simpletest infrastructure that's integrated  
with project_issue.
* Pound more contributed modules with regression tests.
* Start to incorporate generation of simpletests into the security  
review/fix workflow.
* Try to write generic simpletests that would work against any (or at  
least different classes of).  For example, write tests that generate  
both random and specifically malicious content that all output  
filtering modules are fed.

Not only is it all technically feasible, it wouldn't even be *that*  
much work to setup the initial proposal you described, and at least  
the automated simpletests for the core repo on cvs.sec.d.o.

Any objections?  Any volunteers?

Thanks!
-Derek