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@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@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