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

[Derek Wright]

On Jan 17, 2008, at 11:49 PM, Angela Byron wrote:

> New and improved workflow!
> ...
> Sound about right?

Yes, sounds great.  Almost incorporates all of fgm's concerns/input  
about using the same tools for a maintainer's usual workflow, without  
it all happening publicly.  Seems like it should satisfy DragonWize  
and David Metzler's concerns about easy collaboration with other  
project maintainers, transparency, using revision control, beta  
testers, and having familiar tools.  Certainly satisfies me, and I'm  
pretty sure the rest of the security team would agree.

> Looks like, implementation-wise, we need:
>
> 1. Script to sync up non-security team, CVS account-holding d.o  
> users and make them s.d.o users with only basic privileges (create  
> issues/access own issues)

Right.  New role on sec.d.o, and a script to sync all users in the  
"CVS users" role on d.o over to sec.d.o.

> 2. Script (or something) to sync CVS / CVS users between  
> cvs.drupal.org and cvs.security.drupal.org.

The script to sync CVS could just be a fine grained, manually  
triggered, 1 way rsync from different directories in cvs.d.o to the  
different private repos on cvs.sec.d.o.

Users would just be to dump the CVS access tab for each project on  
sec.d.o into the CVSROOT/passwd file for that project's private repo  
on cvs.sec.d.o.

> 3. Script to sync d.o projects / owners / maintainers with s.d.o  
> projects / owners / maintainers.

Seems like pretty trivial stuff here.  I don't even care about all  
the fields.  Title, shortname,  owner, cvs access tab, and perhaps  
body would do.  The rest is fluff as far as sec.d.o is concerned.

> So.. lots of synching. But in the end, I think this actually  
> *saves* the Security Team tons of time, both at the outset (the  
> developer is the one who initiates the process) and also in ongoing  
> education (the team is no longer a "black box" where the developer  
> is waiting for information but instead feeding out useful  
> information to developers as the reviewing process is happening).

Yes.  After the initial work to setup the new system, I think this  
will hugely ease the job of the sec team, and will significantly aid  
in the education aspects of our work.  We can even try to get the  
module maintainers to write the first drafts of the SAs for a change,  
and be more directly involved in editing/reviewing those, too. ;)

> Huge +1 to the automated testing stuff too, but probably best to  
> start simple first. :)

Agreed.  One step at a time, but that's definitely low hanging fruit  
as soon as the basics are up, working, and documented.

>> I'm willing to work with you (or someone) to do this synching  
>> stuff. I don't think I have the time/knowledge to do it alone.

As always, webchick, I'd love to work with you on this.  I'd just be  
thrilled to see some other hands show up.  You and I end up working  
together on a lot of improvements to Drupal on our own (in spite of  
our nearly constant efforts to try to get others involved)...

Cheers,
-Derek (dww)