[development] Slight API change in 4.6.10 and 4.7.4

Darrel O'Pry dopry at thing.net
Thu Oct 19 17:01:17 UTC 2006

On Thu, 2006-10-19 at 08:09 -0600, Greg Knaddison - GVS wrote:
> On 10/19/06, inkfree press <inkfree at gmail.com> wrote:
> > Any methods suggested for determining which modules will break is
> > appreciated.
> Well, in Heine's original message he linked to:
> > Converting 4.6.9 modules to 4.6.10 <http://drupal.org/node/90004>
> > Converting 4.7.3 modules to 4.7.4 <http://drupal.org/node/89999>
> >
> > Converting 4.6.x themes to 4.6.10 <http://drupal.org/node/90021>
> > Converting 4.7.x themes to 4.7.4 <http://drupal.org/node/90024>
> If you read those they show code that will break on an updated site.
> If you browse through your modules and theme for some of those pieces
> of code and they don't look right - you need to update them.
> I believe a list of affected modules is coming from the security team soon.
> Regards,
> Greg

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.

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
time reviewing our security updates and testing them. 

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.

If module X is a key element of my site, and the bug fix breaks it...
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 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
  - solution, and reasoning behind solution
  - links to patches and tar balls
  - parts affected by bug
  - parts affected by fix

I really appreciate the work you guys on the security team do. I'm just
offering these as a suggestion for improvement. 

debian's older policy is a fairly good one, I'm not sure if its still
current in their camp.

More information about the development mailing list