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

[Derek Wright]

On Jan 18, 2008, at 12:14 PM, Angela Byron wrote:

> I'm +1 to its removal, but defer to dww since he knows a lot better  
> than me (or probably most of us ;)) what would be involved here,  
> and how much work it would actually cost/save.

I don't care.  Certainly for phase 1 we can live without.  I think  
everyone understands patches in the issue queue, and many of the  
benefits (including PIFT ("project issue file testing" -- the  
automated sending of .patch and .diff files to a simpletest server))  
would still work without it.  It doesn't let us do automated testing  
*all* of the security-related patches for a given release of core *at  
the same time*, to make sure they don't break each other in any  
interesting and unexpected ways.  But, we've made it this far without  
such automated tests, we can live longer without them (though, sadly,  
the track record on the recent core security releases has been pretty  
bad in terms of QA, and we've had to rev "whoops, sorry we broke  
that" releases a lot more often than I think anyone would like).

That said, if I wasn't spending my time defending my ideas on this  
list, I could probably whip up the CVS rsync code in a few hours.   
The code to dump a CVSROOT/passwd file based on the data in the cvs  
access tab is also a few hour job at most, that one's actually more  
like 1 hour.  So, it's not like it would  have to take weeks of work  
to get the per-project private CVS repos working.  Regardless, I  
can't answer the "how much work would it actually save" question.  It  
basically boils down to how likely is it that developers would use  
it, how much additional confusion/potential for mistakes would it  
introduce, and how helpful for QA would it be.  If people won't use  
it, it's obviously not worth doing.

-Derek (dww)