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

[DragonWize]

1. non-upgraded sites are at risk otherwise there would be need to change.

2. making commit doesn't advertise anything unless you put a
description saying what the security flaw is and how to exploit it.
hopefully it is obvious to not ever do that, no matter when you commit
it.

3. Unless you quietly found the hole by yourself it probably has been
published somewhere (issue queue, etc).

4. committing code give you and others the chance to fix the issue
with out publishing the code.

Given this, I think I am still missing the point.

On 1/16/08, Neil Drumm <drumm at delocalizedham.com> wrote:
> As soon as you commit code you have publicly published the
> vulnerability and put non-upgraded sites at risk.
>
> On Jan 15, 2008 11:58 PM, DragonWize <dragonwize at gmail.com> wrote:
> > I get why you have to wait to create a security node. But why do you
> > have to wait to commit code? I assume there is a point I am missing
> > because we do use a VERSION control system.
> >
> >
> > On 1/16/08, Derek Wright <drupal at dwwright.net> wrote:
> > > Perhaps the docs are too detailed, confusing, hard to find, or
> > > obscure.  I'd like to try in short, plain english to explain what to
> > > do when you think you've found a security problem in your module:
> > >
> > > a) Either you think you find a potential security problem in your
> > > module or a user reports a vulnerability to you.
> > >
> > > b) You *immediately* send email to security at drupal.org about it to
> > > let us know.
> > >
> > > c) You try to analyze the vulnerability to the best of your
> > > abilities, and if possible produce a patch that fixes it.
> > >
> > > d) DO NOT COMMIT YOUR PATCH YET.
> > >
> > > e) DO NOT MAKE A RELEASE YET.
> > >
> > > f) DO NOT MARK YOUR RELEASE AS A "SECURITY UPDATE" YET.
> > >
> > > g) Send your patch to security at drupal.org.
> > >
> > > h) Wait for the security team to reply.
> > >
> > > i) Do what the security team advises you to do.
> > >
> > > j) If/when the security team thinks your vulnerability is real, the
> > > fix is complete, and a security announcement (SA) is ready to go out,
> > > we'll tell you.
> > >
> > > k) Only once an SA is ready for your vulnerability and the security
> > > team is ready to coordinate a release, THEN (and only then) do you
> > > commit your patch to all relevant branches, tag new releases, create
> > > release nodes, and mark them as "Security update" releases.
> > >
> > > l) The security team can then publish your release nodes (which
> > > doesn't happen automatically if they're flagged as a "Security
> > > update") and send out the SA, at which point your users will know
> > > they need to upgrade (both via the security announcement email lists
> > > and RSS feeds, and via the update_status module).
> > >
> > >
> > > Make sense?
> > > Do you really understand the process?
> > > Should I explain why any of these steps are like this?
> > > What else could be done, either via docs or project* UI, to make this
> > > clear?
> > >
> > > Relevant issue:
> > > http://drupal.org/node/210497
> > > "add extra validation to release node form for security update releases"
> > >
> > > Relevant handbook docs:
> > > http://drupal.org/security-team
> > >
> > > Thanks,
> > > -Derek (dww)
> > >
> > >
> > >
> >
> >
> > --
> > Alan Doucette
> > Koi Technology, LLC
> > www.KoiTech.net
> >
> >
>
>
>
> --
> Neil Drumm
> http://delocalizedham.com
>


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