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