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

[Iñaki Lopez]

I think the worry is not how much does the SA help the hackers, but
just how much the security team helps the drupal administrators.
right?

so..


> 1. The hacker already knows when the SA is sent. No benefit gained.

1.   The drupal administrator has a fixed version to download and
receives the SA.

> 2. The hacker doesn't know when the SA is sent but we have already
> told him exactly where the hole is by saying we commit at the same
> time. Yes they could find it extremely easily with out this but we
> just made it slightly easier.

2.   The drupal administrator has a fixed version to download and
receives the SA. Clock is ticking for both.

> 3. The hacker doesn't know when the SA is sent but we haven't made a
> policy about when exactly the code is committed. Can they very easily
> find it anyway? For sure they can, I don't deny that. I also am not
> sugesting remove this step in your short simple guide because it
> provides better security. I am saying that I don't see better in
> security by including it so why make the process harder to understand
> and remember if it doesn't provide a benefit.

3.   The drupal administrator has a fixed version to download and
receives the SA. Clock is ticking for both as in 2.

But I understand that the SA process only works if every drupal
administrator know about the security updates, releases and
advisories, and all contributors follow the guidelines..

> Thank you for your time,
> Alan

Note: I think the way you do Alan, but we should agree not every
module contributor would follow basic security steps (just a look to
some modules would clarify this), and the security team is trying to
do it's best to not let drupal administrators alone.

>
> On 1/16/08, Derek Wright <drupal at dwwright.net> wrote:
> >
>
> > On Jan 16, 2008, at 9:13 AM, DragonWize wrote:
> >
> > > 3. Unless you quietly found the hole by yourself it probably has
> > > been published somewhere (issue queue, etc).
> >
> > If everyone was following instructions, they'd report the hole to
> > security at drupal.org, not the issue queue.  Whenever we find security
> > problems reported publicly in the issue queue (which sucks, but it
> > does happen), we try to immediately unpublish the issue and move
> > discussion back into the security team's issue tracker.  Of course,
> > it's often too late at that point (people already got emails about it
> > if they're subscribed to the queue, someone might have already seen
> > it, etc, but we do the best we can...
> >
> > > 4. committing code give you and others the chance to fix the issue
> > > with out publishing the code.
> >
> > I can't parse what you mean here.  I'm not sure it matters, since it
> > smells like security through obscurity to me, but perhaps you could
> > clarify your point?  How is committing the code not "publishing the
> > code"?
> >
> >
> > Oh, and one more good reason not to just go off and commit your patch
> > as soon as you think you fixed the problem...
> >
> > The security team carefully reviews your patch, and usually audits
> > the rest of your module at the same time.  Maybe you fixed 1 hole,
> > but missed 3 others.  Maybe your "fix" is still vulnerable to some
> > case you're not thinking of.  Maybe your "fix" introduces a bug or
> > otherwise makes life miserable for users trying to upgrade.  Who
> > knows.  Point is, you want to wait for the security team to review
> > your patch, audit your code, and propose improvements to your
> > solution (if there are any to be made).  All of this should happen
> > privately, between you and the security team, not publicly via a
> > stream of CVS commits.
> >
> > Make sense?
> >
> > Thanks,
> > -Derek (dww)
> >
> >
> >
> >
>
>
> --
>
> Alan Doucette
> Koi Technology, LLC
> www.KoiTech.net
>