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

[DragonWize]

@Angie & Derek

As a new drupal contributor I have no intimate knowledge of who has
access to what are areas of d.o, how the access is handled, what is
and isn't possible with some of the code behind the scenes, etc., so I
am entrusting you as my experts in that area. I don't specifically
have any objections because I am not able to fully understand the
implications of your proposals.

My two main concerns are:

1. The process has to be simple (ie not like U.S. Tax laws :))
2. Don't stop me from developing my module. As drupal becomes more a
part of my business and my livelihood, taking 2 weeks off is not an
option.

If your proposals fulfill these objectives then count me in.

Thank you,
Alan

On 1/18/08, Derek Wright <drupal at dwwright.net> wrote:
>
> 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
>
>
>


-- 
Alan Doucette
Koi Technology, LLC
www.KoiTech.net