[development] Slight API change in 4.6.10 and 4.7.4
gerhard at killesreiter.de
Thu Oct 19 17:20:43 UTC 2006
Darrel O'Pry wrote:
> dopry at 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.
> 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.
Policies don't make security releases.
P.S.: I've seen a preliminary list of modules that will need some
tweaking. Nothing really important was on that list.
More information about the development