by David Snopek on January 26, 2016 - 7:51am

As you may know, Drupal 6 will reach End-Of-Life (EOL) on February 24th, 2016. This means the Drupal community (including the Security Team) will no longer support Drupal 6!

However, a small group of commercial vendors will collaborate with the Drupal Security Team to take on Long-Term Support of Drupal 6! And myDropWizard is one of those Drupal 6 long-term support vendors. :-)

In this article, we'll answer the following questions:

  • What specifically will happen on February 24th?
  • What is the official Drupal 6 LTS?
  • How will the process work?
  • What will customers need to pay for?

Read more for the answers!

What specifically will happen on February 24th?

The most noticible thing that will happen on February 24th, is that all Drupal 6 contrib modules will be marked as unsupported.

This means that the download will be marked in red on Drupal.org, and that the "Update" module (if you have installed) will start telling you that all your modules need to be updated.

It may also mean that any new bugs or support requests posted to a Drupal 6 contrib module will simply be closed. And, of course, the Drupal Security Team will stop working on any issues that affect Drupal 6 core or contrib modules.

Also, the data that the "Update" module depends on could get turned off at any time! This could be weeks or months later - but the Drupal Association is paying a substantial hosting bill for this, and obviously they'd prefer to spend those funds on the supported versions of Drupal. So, you won't be able to depend on it anymore, in general.

(We're considering creating a replacement for the "Update" module once this happens! We'll make a seperate announcement about that if we decided to go for it.)

What is the official Drupal 6 LTS?

So, what makes the official vendors special?

  1. We were vetted by the Security Team (both for technical ability and trust). The Drupal Security Team put out a call for applications to be on this list, and many more applications were received than were accepted.
  2. We will get confidential information from the Security Team about possible Drupal 6 vulnerabilities. If a Drupal 7 or 8 security issue is reported in Drupal core or one of the modules we support, then we'll check to see if the issue also affects Drupal 6. If so, we'll make a Drupal 6 patch that'll get released at the same time as the Drupal 7 or 8 one.
  3. We will provide our security patches publically at the same time we provide them to our customers. In exchange for the confidential information we get, we're required to make all our patches available publicly - not just to our customers.

Personally, I think this is a good balance of things that are good commercially for the vendors taking on this support, and good for the community, even if they don't buy a support plan from one of the vendors.

How will the process work?

Internally, the Drupal 6 LTS vendors will be following the very same processes as the Drupal Security Team, using the same tools. The only difference is that we'll be doing the work, rather than taking resources away from the all-volunteer Drupal Security Team.

If a security issue also affects Drupal 7 or 8, the Drupal 6 patch will be released at the same time (or shortly after).

Patches will be put in the Git repo for the D6LTS project on Drupal.org, and will be announced in the issue queue.

No more Drupal 6 core releases will be made on Drupal.org - but we'll (probably) continue to make full releases of Pressflow 6 (a fork of Drupal 6, hosted on GitHub).

It's still unclear where or how full releases of Drupal 6 contrib modules will be made. If the maintainers are willing, we might be able to make them on Drupal.org - but possibly not. It's up to the module maintainer if they'll grant us access or not.

What will customers need to pay for?

As noted above, we're required by our agreement with the Drupal Security Team to post all our security patches publicly.

So, even if you don't buy a Long-Term Support plan from one of the vendors, you could still watch for the security patches we create and use them!

However, we're not supporting ALL contrib modules. We're only going to support the contrib modules used by our customers. Each of the vendors will be maintaining lists, and providing them to the Drupal Security Team so they know which issues to include us on.

So, if you don't pay for a Long-Term Support plan from one of the vendors, some of your modules might NOT receive security patches at all!

And if your site is hacked using a vulnerability that has no security patch - you're on your own.

But if you buy Drupal 6 Long-Term Support from myDropWizard, we'll help you with remediation if your site is hacked - regardless if a patch already exists or not!

This is a real risk, since fewer people will be looking at Drupal 6 code or reporting issues, while Drupal 6 is still a very tempting target for hackers (Drupal.org reports ~125,000 sites still running Drupal 6).

All this and more on Modules Unraveled!

Last week, I was on the Modules Unraveled podcast, talking about this same information (and more!):

(Check out my wicked wizard beard! ;-))

If you have any more questions, please feel free to post in the comments below.

And if you're interested, check out our Drupal 6 Long-Term Support plans!

Want to read more articles like this?

myDropWizard.com blog Subscribe to the myDropWizard.com blog and recieve e-mail updates when new articles are published!

Comments

Hello David,

For the 4th questions u mentioned as if we don't buy a Long-Term Support plan from one of the vendors also we could still watch for the security patches created by your team. May i know where those patches are publicized. So that we can use it for customer who are not ready pay invest more money on maintenance .

They are added the Git repo for the d6lts project on Drupal.org, which you can browse here:

http://cgit.drupalcode.org/d6lts/tree/

However, not all contrib modules are supported by the vendors! We only support the modules used by our customers. So, if a vulnerability is found in a module that none of the vendors support (for example, like the recent vulnerability in the Hybridauth module) the fix won't be ported to Drupal 6.

So, while you could make customers safer by using the patches there, there might not be patches for all the security vulnerabilities that affect a customer.

I hope that helps!

Add comment