[development] Slight API change in 4.6.10 and 4.7.4

[Darrel O'Pry]

On Thu, 2006-10-19 at 19:20 +0200, Gerhard Killesreiter wrote:
> 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.

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.