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

[Derek Wright]

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)