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

Greg Knaddison greg at pingvox.com
Wed Jan 16 19:19:46 UTC 2008

On Jan 16, 2008 4:59 PM, DragonWize <dragonwize at gmail.com> wrote:
> 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.

This is a false assumption and several people have tried to point it
out to you.  Continuing to assume otherwise doesn't make it true.
Making the commit does advertise a lot.

The important thing is not the amount of time that the security hole
is in the code. The most important thing is the amount of time between
general knowledge of the hole and the upgrade of all sites that are
running that code.  So, what can we do to make that timespan small?

>From the end of process to beginning
-Make it really easy to perform the upgrade - aside from hosted
services I think we've done about as much as we can here
-Make it hard for users to be ignorant of the released fix
(update_status.module, security maililng list and RSS)
-Fix the security bug

So, if we fix the bug in CVS and then have to wait (any amount of
time) before making the announcement then that's not helpful to end
users and it introduces the possibility that someone will figure out
what the commit meant.

Fixing a hole in cvs is only the very beginning of running a secure project.

We do run this process in a very standard way.  If nothing else is
convincing to you about why the process is this way, the fact that it
is industry best practice should help.


Greg Knaddison
Denver, CO | http://knaddison.com
World Spanish Tour | http://wanderlusting.org/user/greg

More information about the development mailing list