On Jan 16, 2008 4:59 PM, DragonWize <dragonwize@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. Regards, Greg -- Greg Knaddison Denver, CO | http://knaddison.com World Spanish Tour | http://wanderlusting.org/user/greg