(Changing the subject, so we do not pollute the original thread)<br><br><div class="gmail_quote">On Jan 23, 2008 9:33 AM, Ivan Sergio Borgonovo <<a href="mailto:mail@webthatworks.it">mail@webthatworks.it</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">On Wed, 23 Jan 2008 11:47:34 +0000<br>"Stephane Corlosquet" <
<a href="mailto:scorlosquet@gmail.com">scorlosquet@gmail.com</a>> wrote:<br><br>> As some pointed out, the one who reports a security issue and the<br>> module maintainer(s) should be more involved in the fixing process:
<br>> 1- better communication and transparency between reporters,<br>> maintainers and sec team<br><br></div>This sentence got my attention.<br><br>Recently I had to deal with the sec team and the experience was not
<br>that satisfying.<br><br>I'm very sorry to be missing the time for superior diplomacy because<br>I'm very short on time so I'll go straight to the point.<br><br>I'm referring to <a href="http://drupal.org/node/198162" target="_blank">
http://drupal.org/node/198162</a><br><br>My experience...<br>There may be a bit difference in details to what actually happened,<br>without changing the substance of the experience, I've no time to go<br>through email and IRC logs to make a precise chronological report.
<br><br>- I tried to intercept people on IRC asking what to do.<br>- nobody was able to point me to guideline to how to report a<br>security issue, I had the impression no one was responsible for sec<br>issues.</blockquote>
<div><br>It is here <a href="http://drupal.org/node/101494">http://drupal.org/node/101494</a> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>- people even laughed at me when I said the problem may be deep into<br>core<br>- when I said that I thought that SQL injection could be exploited<br>just on Postgresql, I received even more laugh. Later Heine[1]<br>found a way to do privilege escalation with MySQL too.
<br>- even if I submitted a quick patch nearly contextually to the sec<br>report there was a long lag between the public SA<br>- <a href="mailto:security@drupal.org">security@drupal.org</a> doesn't even send an automatic reply. That's
<br>terrible... I had to go to IRC to ask if the message was received.</blockquote><div><br>We get a lot of spam on that mailing list, so it is moderated. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>- after the sec team was informed I didn't get any news back, I had<br>to insist to get an idea about when a SA was going to be issued, how<br>they were planning to deal with the vulnerability etc...</blockquote>
<div><br>The team is entirely volunteer driven, and the amount of work is very <br>large for it to handle. We recently asked for more volunteers and got<br>maybe 3 responses total.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>- missing transparency, having a patch ready it was really<br>uncomfortable to decide if it was the right moment to disclose the<br>problem autonomously or wait for an official response<br></blockquote><div><br>The process mentioned above spells it out. You should coordinate with
<br>security and only commit when the SA is ready.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>I tend to be forgiving in things related to personal character of
<br>people. I don't mind people to be opinionated or even rude, just as<br>things get done the proper way.<br><br>I tried to play nice even when I had to deal with these issues and<br>behave the best I could considering the information I had. Insisting
<br>that the vulnerability was important (several high profile sites<br>exposed) and trying to sync with sec team even if there was no<br>official response. I even did some further autonomous research to see<br>if other module could be involved.
<br>Some of the people I had to deal with absolutely didn't deal with the<br>issue in a way that promoted responsible disclosure.<br><br>I may had behaved like an asshole (I don't think so) but still, as I<br>calmed down and manage the stuff at my best passing over "personal"
<br>opinions so I'd expect the same from the people on the other side.<br><br>Transparency and a honest communication channel are vital to this kind<br>of issues.<br><br>It may had been a chance, bad luck, I don't want to point fingers to
<br>anyone. I'd just like to point to problems so that things may get<br>better... and this should also say something about serious Postgresql<br>support and DB knowledge.<br><br><br>As a side note I think that due to the success of Drupal and its
<br>larger community of developers this policy is not anymore suitable<br>for the project:<br>The Drupal philosophy - Escape or filter when appropriate<br><a href="http://drupal.org/node/101495" target="_blank">http://drupal.org/node/101495
</a><br>on a larger and larger code base, with many newcomers "when<br>appropriate" is a slimy concept and relying on db_query didn't show<br>to be a "catch all" solution (not to mention XSS and other kind of
<br>niceness.<br>Drupal API is its most valuable asset. Encapsulation makes an API<br>more valuable. If people have to discover "when it is appropriate"<br>the API becomes less valuable. If people can't understand when it is
<br>appropriate, it is risky [2].<br><br><br>[1] Heine did a great job and I hope he understood I really didn't<br>enjoy to put pressure on him, but he was the only reasonable<br>communication point I had with sec, and I had to communicate through
<br>his personal email address since nothing ever came back from security@<br>I couldn't even think if he was replying in the name of the sec team<br>or not.<br><br>[2] waiting for prepared statement since I love to pass nulls to the
<br>DB<br><font color="#888888"><br>--<br>Ivan Sergio Borgonovo<br><a href="http://www.webthatworks.it" target="_blank">http://www.webthatworks.it</a><br><br></font></blockquote></div><br><br clear="all"><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.