On Jan 16, 2008 12:13 PM, DragonWize <dragonwize@gmail.com> wrote:
1. non-upgraded sites are at risk otherwise there would be need to change.
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.
3. Unless you quietly found the hole by yourself it probably has been published somewhere (issue queue, etc).
4. committing code give you and others the chance to fix the issue with out publishing the code.
Given this, I think I am still missing the point.
On 1/16/08, Neil Drumm <drumm@delocalizedham.com> wrote:
As soon as you commit code you have publicly published the vulnerability and put non-upgraded sites at risk.
On Jan 15, 2008 11:58 PM, DragonWize <dragonwize@gmail.com> wrote:
I get why you have to wait to create a security node. But why do you have to wait to commit code? I assume there is a point I am missing because we do use a VERSION control system.
On 1/16/08, Derek Wright <drupal@dwwright.net> wrote:
Perhaps the docs are too detailed, confusing, hard to find, or obscure. I'd like to try in short, plain english to explain what to do when you think you've found a security problem in your module:
a) Either you think you find a potential security problem in your module or a user reports a vulnerability to you.
b) You *immediately* send email to security@drupal.org about it to let us know.
c) You try to analyze the vulnerability to the best of your abilities, and if possible produce a patch that fixes it.
d) DO NOT COMMIT YOUR PATCH YET.
e) DO NOT MAKE A RELEASE YET.
f) DO NOT MARK YOUR RELEASE AS A "SECURITY UPDATE" YET.
g) Send your patch to security@drupal.org.
h) Wait for the security team to reply.
i) Do what the security team advises you to do.
j) If/when the security team thinks your vulnerability is real, the fix is complete, and a security announcement (SA) is ready to go out, we'll tell you.
k) Only once an SA is ready for your vulnerability and the security team is ready to coordinate a release, THEN (and only then) do you commit your patch to all relevant branches, tag new releases, create release nodes, and mark them as "Security update" releases.
l) The security team can then publish your release nodes (which doesn't happen automatically if they're flagged as a "Security update") and send out the SA, at which point your users will know they need to upgrade (both via the security announcement email lists and RSS feeds, and via the update_status module).
Make sense? Do you really understand the process? Should I explain why any of these steps are like this? What else could be done, either via docs or project* UI, to make this clear?
Relevant issue: http://drupal.org/node/210497 "add extra validation to release node form for security update releases"
Relevant handbook docs: http://drupal.org/security-team
Thanks, -Derek (dww)
-- Alan Doucette Koi Technology, LLC www.KoiTech.net
-- Neil Drumm http://delocalizedham.com
-- Alan Doucette Koi Technology, LLC www.KoiTech.net
Alan There is an RSS feed here http://drupal.org/cvs It has all the commits that went to the repository. Also cvs.drupal.org has all the info too. You can bet that black hat hackers are monitoring this (and other popular projects) for exploits. If you are a maintainer for a project and commit something here saying: "Fixed large SQL injection hole in module", with no announcement or release for it, then it is an invitation for an exploit. This is why it has to be coordinated with the SA. Yes, not all sites will upgrade the minute the release comes out, but there is nothing that can be done about that beyond the responsible disclosure process we are doing. -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting.