Security backports for the Drupal LTS concept

greggles's picture

How do you plan to backport security fixes?

Will you just wait for the release of Drupal 6 and backport them?
Do you plan to offer a system and some method to promote people reporting vulnerabilities in Drupal 5 even if it is EOL?


d.o integration and improvement

C_Logemann's picture

I think backporting security fixes is a good first step to make older drupal versions more secure.

If it's possible to integrate in the main security process especially for reporting security problems and announcing fixes we should do. If not we need an own system for that.

I think the biggest problem is to create strategies and getting more manpower to handle LTS. The integration of a robust LTS concept in should be a part of the normal improvement like the current GIT Migration.

My company: Nodegard GmbH

broad support vs. narrow support

greggles's picture

I think the git migration had broad (and high) support whereas this effort will likely have relatively narrow support.

Creating an official LTS is only likely to happen if you can convince folks like Dries, Drumm (as 5.x branch maintainer), Killes (as d.o infrastructure maintainer) to be in favor of it which seems unlikely.

LTS is great

keesje's picture

Greggles is right.
This topic is being brought up from time to time over the past years.
I was (once) too looking for ways to make a LTS version of Drupal work.
I too think it stinks that such a solid framework is loose sand when it comes to lifespan.
The reaction I got several times: "He, Drupal is free, we cant support more than 2 major branches, pay for it if you want a third to be maintained".
Understandable. But, paying for maintainment of an older, or LTS branche isn't realistic. Who to pay? You have to have ALL people maintaining core- and popular 3th party code to be willing to support this, payed or not.
This cannot be done from the outside. The initiative have to come from the core team and key community members, top down.

Drupal developer Nederland

contrib module support?

greggles's picture

There are now two publicly announced security vulnerabilities that affect contributed modules for 5.x only and therefore will not be addressed by the Drupal security team:

  1. Panels for 5.x
  2. Custom Pagers for 5.x

Folks interested in making Drupal 5 an "LTS" will need to consider how they will address contributed modules for 5.x. You can find more articles by Justin about Drupal:

how about just reporting the problems?

damien_vancouver's picture

Given that the idea of Drupal LTS without support of any of the active development core is contrary to the official policy (and thus not feasible in real life)...

how about the LTS effort be simplified to just focus on announcing the problems for people who choose or have no choice to stay on the older versions. The reality of how it works right now is that only one group of people are well infromed about these vulnerabilities, and these are the blackhats, hackers, and spammers out there. While those people who are the legiitimate site owners or operators just stuff their head into the bucket of sand and hope nothing goes wrong with their site which previously was patched up. Given the fact people just two years ago were forced to develop in drupal 5 because of the lack of contrib modules for d6, this is a pretty crappy situation.

Given that a "real" LTS effort with backports and testing is unlikely to ever really get off the ground, perhaps those interested in contributing and who are still stuck (for whatever reason) with these old "ticking time bomb" sites can at least inform one another of what is vulnerable. That way site owners/operators can make an informed decision about what unpleasant compromises to make (for example "uninstall panels".... A bitter pill to swallow for sure if you spent $50,000 on custom panels development!)

What I propose is we just list the security vulnerabilities from drupal 6 or 7 that are also found to be in drupal 5. Even cursory comparisons of what changed in the patch fixing the security problem can allow you to identify if the same code exists in the same format in Drupal 5.

I think it's a more realistic goal to accomplish, instead of saying "gee i guess that can never happen" and letting the blackhats win by default. In some cases, backports might result, which would be a good thing too. (For instance, what if a critical CCK bug comes out. Every drupal 5 site in the world is not going to uninstall cck).

Some general thoughts about this issue as a whole... Drupal as a community just shunning the old versions like they are black sheep in the face of such problems (not if but when they occur) is not to the benefit of the community. Drupal the movement has grown exponentially in the last couple years. this is good, and very exciting for everyone involved. However to keep this momentum, we have to not totally screw over everybody 2 years (?) from now when Drupal 6 is suddenly declared obselete. My point is that this problem is only growing worse, as drupal gets more popular. I believe proper education at the outset, and responsible site building by development shops is the solution. All developers should make their potential clients aware of the issues surrounding a modern CMS website, which is that you are going to have to pay a bunch more (maybe evne more than you did for the first version) to upgrade the site + all its content baggage when it expires. It is bordering on criminal irresponsibility in my opinion to not educate customers on these facts first, before sealing the deal to build their site. But I am bitter sysadmin guy, so of course I think that. :)

Tyrell: Would you... like to be upgraded?
Batty: I had in mind something a little more radical.
Tyrell: What... what seems to be the problem?
Batty: Death.
Tyrell: Death; ah, well that's a little out of my jurisdiction. You...
Batty: *I want more life, father!*
- Blade runner, 1982

Perhaps use the contrib module infrascture

johnbarclay's picture

Perhaps make a contrib module "drupal_lts" and have versions for each drupal version. This would allow lts to leverage the drupal project infrastructure such as the issue queue and releases. The module could contain patches and, potentially, the ability to identify unpatched core and contrib within a site.

lts module/project

johnbarclay's picture

I went ahead with this to see how it would go. I think I'll start by putting an issue in for each security fix in 7.1/7.2. The ones that aren't relevant to Drupal 5 can just be tagged as such. It will be the first 5.x module started in a while; I hope the branch and tagging will allow a 5.x branch.

backlink to this group?

C_Logemann's picture

Hello John,
thank you for your initiative.
I have added a link to your project in the group description and on the resources page:
Please set a backlink to this group on your project page.
edit: I see you have added the link at the resource section as "read documentation". Maybe renaming the link as "LTS-Group" or something like this will be better?

I've just started contributing code on d.o but I will try to help as good as I can with your project.

kind regards,
Carsten Logemann

My company: Nodegard GmbH


johnbarclay's picture

I added a link in the body of he page. I also gave you project rights to edit the project page and edit the issue queue; feel free to hop in.

lts module going ok

johnbarclay's picture

I added some sample patches and hooked into the status report. This may be the first new drupal 5 module in a while.

Would love some feedback on the approach and a look at the patches in the issue queue.