I'm not talking about detail explanation of what and how reported security issue can harm Drupal site. But may be some clue in order to deal with it.
Our public SAs don't give details of how to exploit vulnerabilities, while of course the commit logs are there (but it's not always obvious from them either) - this is by design so that we're not simply giving out instructions to people on how to hack sites which don't upgrade in a timely fashion (of which there are many). However, to fix an issue, you need to know how to exploit it, so I'm not really sure what you're asking for here. If a contributed module is extremly insecure and there's not an immediate fix for it, we unpublish the module until an SA can be released for it (and you'll be informed that the module has been 'revoked' by update status).
Or may be we need some special procedure to subscribe to such information.
You can get SAs as soon as they're published via e-mail or RSS from http://drupal.org/security.
But I'm sure that many of us would like to know what is going on with fresh security discoveries.
Those who want to help fix new discoveries can offer to join the security team, I don't think 'would like to know what's going on' is sufficient though. Nat
Victor Kane wrote:
On Wed, Oct 1, 2008 at 12:40 AM, Drupal Developer <lapurd@gmail.com> <lapurd@gmail.com> wrote:
Wow, I would like everybody to notice something right here.
In the message I reply to, Matt Farina said:
"The security team handles things in a tight way. When something is reported it's not opened up to the world. If the issue is valid it's handled behind closed doors until a fix and advisory is sent out." /end of citation/
I thought that Drupal is an open community of open source developers working under GPL license. Does it mean that ALL issues have to be openly reported to all community for everybody to review? Don't you all think that handling security issues behind closed doors until a fix and advisory will be sent out is sound more like corporate way of thinking on a way to develop something proprietary?
It's a GPL license, that's why I am sure the security team is open to anyone who is interested in helping out on that very important front.
But GPL doesn't mean that we have to be stupid as a community, and advertise exploits before a fix can be made and people given a chance to have a security fix to use.
Just as the corporate world, as we are finding out all over the world these days, certainly has no "monopoly over intelligence", or over doing what's best for all, open source communities can be smart too.
There's nothing proprietary about that. Quite the opposite, in fact: defending ourselves against conspiracies to wreak havoc certainly has to be the right of open source communities,
Victor Kanehttp://awebfactory.com.ar
I'm very concern about that and invite everybody to collaborate on this one.
Does Matt represent a real situation at this matter in Drupal development community? If not, then I'm sure that many people would like to know exactly what the process is for handling security issues from the moment they have been reported?
Thanks in advance, Alex
matt@mattfarina.com wrote:
Jon,
Thanks for your interest in this. I'm interested in this as well.
Some of their concerns seem to be over some misconceptions that might help to be cleared up.
Someone correct me if I'm wrong but drupal 4.0 was 10 major releases ago. 100 + advisories over 10 major releases isn't as many as the 3 which the numbering might look like. Before drupal 5 the major releases were point releases and not full number releases. On top of that, the security advisories cover contributed modules and have included other libraries used by drupal modules, such as getID3.
The security team handles things in a tight way. When something is reported it's not opened up to the world. If the issue is valid it's handled behind closed doors until a fix and advisory is sent out. Those advisories come out on Wednesdays so they can immediately be acted on.
I would be very curious as to what it would take to certification as well as their concerns.
Matt
Quoting Jon Saints <saintsjd@gmail.com> <saintsjd@gmail.com>:
On a recent project for the US government, half way through the development process, our work was stopped by a government security review which said that Drupal (and open source software in general) is not suitable for use in government projects that house personal information due to security concerns.
Because our project had been approved by higher ups within the department, we were paid for our work up to that point and asked to stop. Now, its up to the tax payers to foot a much larger bill for other developers to implement a proprietary and more "secure" (or secretive) solution.
The "transparency" of the Drupal project was one of the government's big objections. In their eyes, disclosing and fixing securit holes in a timely manner, is not the same thing as security. They pointed out the 100+ security disclosures since drupal 4.0 as a reason that the system could not be used. We noted that all these disclosures where quickly addressed, but that did not seem to matter.
I notice other governments around the world are using Drupal with great success and savings to citizens:http://buytaert.net/new-zealand-government-using-drupal
The standards we would need to meet with drupal are:http://csrc.nist.gov/groups/SMA/fisma/index.html
My questions are the following: - Have any other developers run into this cerfication problem before? - Is anyone in the drupal community currently working to get Drupal certified for use in US Government projects? - Does anyone know exactly what cerfication would require from a development standpoint?
If there is interest in investigating this type of certification further, let me know. NIST, the department that certifies software, is just down the road from me. I could go investigate further.
Thanks Jon