On Thu, 2006-10-19 at 19:20 +0200, Gerhard Killesreiter wrote:
Darrel O'Pry wrote:
dopry@bbox:~/public_html/drupal-4-7/public_html/sites/default/modules$ cat */*.module */*.inc | wc 15672 55392 508132
You mean browse through 15K lines of code? It's crazy to expect that of a site administrator. Remember we are developing for non-developers.
It is open source, ie it is part of the "scratch your own itch" movement. "your own" refers to developers.
Umm yeah I'll volunteer. I'd patch my modules before a disclosure, if someone would be nice enough to let me know it needs to be done. I may even patch things that I don't maintain.
This is the second security update the breaks things in the process of fixing them. Which isn't so good in my opinion. We need to take more
We of course did this just to piss people off...
No at all you old curmudgeon :). I think we can be more careful and there can be a larger review team for security updates I'd be happy to participate in that.
If we are going to change core in a way that will break modules, the affected modules need to be identified and their maintainers notified so a concerted effort can be made to provide end-users a real security fix, not just a partial. It is unfair to expected administrators and end-users to edit a module file.
It is unfair to expect unpaid volunteers to provide better support than the security departments of multi-billion dollar companies. At drupal.org you at least _get_ security updates...
I'm only expect volunteers do their best, be open to suggestion, and respond with quality rebuttal if they're capable. I'm simply pointing out a problem I see in the process. I'm not suggesting a whole lot more in the way of work for the security team. I'm even offering suggestions for improvement and my time to assist.
If module X is a key element of my site, and the bug fix breaks it...
Then you need to hold back the bugfix for a day or two while either you or somebody else fixes it. You still have an option to disable that module for that day or two.
did you read the phrase 'key element'. eg) you operate an aggregator site using aggregator2, a bug fix two core changes the return value of feed parsing. The security team releases the update. Did the developers of the affected modules get notified, did they have a chance to prepare a new version to coincide with the security update release? grep is a powerful tool for finding these things and I hear its fairly stable at this point. My suggestion is to hold back the disclosure for a day or two while contrib module maintainers who care have an opportunity to bring their modules up to speed, and to provide time for a more thorough review of the suggested changes.
I think a reasonable order of disclosure would be --security team - analyze problems, determine scope of change and its impact
--distro maintainters & module maintainers - give a set period for updates (1-2 days?)
--public disclosure - release with notice of error - example of how to exploit
Weren't you the one who was concerned about script kiddies?
- solution, and reasoning behind solution - links to patches and tar balls - parts affected by bug - parts affected by fix
full disclosure means taking the time to fix an exploit internally, testing the fix, and fully disclosing the fix and the exploit so the community at large can verify and test your work. That includes inviting the script kiddies to test their stuff.
Yeah, get us some funding for a paid security team and you can get all this. We could even patch affected modules.
No, just contacting the maintainers and giving them a period before disclosure is sufficient. At that point it is no longer on drupal core, its security team, or core maintainers. Its on the head of the contrib maintainer. Its a grep and some emails, maybe 30 minutes of someones time if that.
I somehow doubt this.
I appreciate the work, regardless of your doubt. Otherwise, I wouldn't engage in this dialogue, provide my opinions, or look at other people's processes for an example.
offering these as a suggestion for improvement.
Which is totally pointless considering how understaffed we are.
Then why not let people know the security team is understaffed and recruit some people. I'm sure there are people with a vested interest in making sure that part of the machine runs well.
debian's older policy is a fairly good one, I'm not sure if its still current in their camp. http://lists.debian.org/debian-devel/1999/08/msg01933.html
Policies don't make security releases.
And bad security releases don't make very inviting platforms. I agree policies don't make releases, unfortunately I'm not a member of the security team, so neither do I.
Cheers, Gerhard
P.S.: I've seen a preliminary list of modules that will need some tweaking. Nothing really important was on that list.
Cool. It would be nice to make an effort to cover those before disclosure. It save the sec team from having to rush and gives a few days for testing waiting for contrib developers to get it together as well.