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.
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...
time reviewing our security updates and testing them.
Thanks for volunteering for the security team...
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...
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.
You have just publicly disclosed a vulnerability in my site that I cannot address.
/etc/init.d/apache stop
If I am a simple site administrator and not a developer, what boat am I in now? I can fret until my required module is updated. That is about it. This kind of information also provides a targeting vector for script kiddies.
drupal sites running module X are unlinkely to have applied patch y google: Drupal + Module X (or select css classes and ids from Module X)
I think that this event is rather unlikely.
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
Yeah, get us some funding for a paid security team and you can get all this. We could even patch affected modules.
-----------------------------------------------------
I really appreciate the work you guys on the security team do. I'm just
I somehow doubt this.
offering these as a suggestion for improvement.
Which is totally pointless considering how understaffed we are.
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. Cheers, Gerhard P.S.: I've seen a preliminary list of modules that will need some tweaking. Nothing really important was on that list.