[development] Slight API change in 4.6.10 and 4.7.4

[Gerhard Killesreiter]

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.

/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.