[development] backporting sec patches

Ivan Sergio Borgonovo mail at webthatworks.it
Tue Apr 29 23:00:59 UTC 2008

On Tue, 29 Apr 2008 23:31:21 +0200
Heine Deelstra <hdeelstra at gmail.com> wrote:

> Ivan Sergio Borgonovo wrote:
> > Since I will need a longer life cycle... I know I'll have to
> > support security patches for at least one more older release
> > starting from 5.X.

> Thank you for the offer. Openflows is doing something similar for
> Drupal 4.7 core.

I didn't understand perfectly their release policy... but well that's
not different from what I was planning to do.

> > I could start to take care of this in a *very* informal way. That
> > means that I'll make aware people that they CAN'T relay on this
> > service and see how it goes.

> If people cannot rely on this service, how can they make the choice
> to skip upgrading for two releases?

Because they don't have other choices other than Openflow? and I'm
advertising what I'll do. I think that once you volunteer and
advertise a service you take a responsibility. I advertise the
service I can handle.

> > What I know I won't be able to handle is assisting in fixing
> > security problems in older modules or providing a full tar of an
> > older patched version or manage DB update path.

> Whether a burglar comes trough the door (core) or the window
> (contrib) doesn't matter much; you still loose your toys. This is
> why the sec team also started doing security announcements for
> contributed modules.

People always says scratch your own itch. I've to refresh my security
knowledge and I think I'll need to support Drupal for a little
longer. Till now my sites depended on very few modules.
If I'll see an announcement that involve a bug in a module but can be
fixed in core I'll try to fix it.

That could be a starting. It doesn't have to be official, it doesn't
have to be hosted on drupal.org too.
If I can be informed of security problems in current version before a
public announcement is made I'll write a patch for D(N-2) and publish
it somewhere.

> In exchange for continuing support for 5.x what needs to happen (at
> least):

> - Dropping security support for all alpha, beta and dev releases.
> - Buy-in from the rest of the team.

I'm planning to take care of just the latest D(N-2) and see how
things go. People may complain because of lower performance
introduced by a patch, the sec team may be not willing to wait my
patch for the older version, I may find harder than expected... etc...
I'd like to try and see.
It could be a chance to understand better how things work internally
and what is the release process.

Ivan Sergio Borgonovo

More information about the development mailing list