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

[Derek Wright]

On Jan 17, 2008, at 11:27 PM, Khalid Baheyeldin wrote:

> First, is it scalable?

Very.  In fact, it's VASTLY more scalable than the existing process/ 
workflow.

> It requires significant security team's manpower.

Not at all.  Only to get the initial sync stuff working.

> Second, a snapshot can get stale vs. the code at cvs.d.o , and all  
> sorts of interesting stuff can happen.

That's why we'll still try to use patches in the (sec.d.o) issue  
queue, and if we have to, we just re-rsync the CVS dir on cvs.d.o to  
that project's private repo on cvs.sec.d.o again while we're working  
on something, re-apply the patches, etc.

Alternately, we could consider using vendor branches on these private  
repos to help merge local changes.

If we wanted to get really crazy, we could start to experiment with  
distributed revision control (e.g. git.sec.d.o) to help manage  
private repos for _some_ of the projects on sec.d.o.  I know people  
who've have great luck importing a CVS checkout, "CVS" directory and  
all, into other revision control systems.  They make local  
modifications and commit to the other RCS.  Then, they run "cvs up"  
in the checkout, the CVS directory kicks in, CVS tries to merge in  
upstream changes, you resolve conflicts, and commit that again  
locally to the alternate RCS.  Could work great, at least for  
projects where the maintainer is already familiar and would rather  
work with another tool for this task, but that would depend at the  
very least on people helping to complete the to-do list here:

http://groups.drupal.org/node/8102

and then implementing other versioncontrol API backend modules for  
whatever tool(s) they wanted to be able to use for this.


> Third, back synching the cvs-security.d.o to cvs.d.o after the SA  
> process
> is done is a lot of work, and could introduce errors.

Not at all.  It's just the identical workflow for maintainers to  
commit an RTBC patch from an issue to their official cvs.d.o  
directory.  Even if we got crazy with other RCSs, you just update  
your workspace to the latest copy in $RCS, which is itself a "Locally  
modified" CVS workspace from CVS's perspective.  You run "cvs diff - 
up" and you've got a perfectly synced, clean patch to apply upstream.

-Derek (dww)