As many of you are likely aware, there's discussion at https://drupal.org/node/2136029 on the idea of extending the life of Drupal 6.
Dries would like a "decision" from the security team's perspective and I thought it would be good to ask folks who are outside of the team, but still interested in the topic of Security.
Given that many people support the idea of upgrading from version X to version X+2 to reduce the cost of upgrading your Drupal sites. Currently that's not possible if you explicitly follow the supported release schedule and use almost any contributed projects (modules and themes) because those projects are not likely to be fully ported by the first day of the release of X+2.
Given also that project maintainers often don't want to maintain "old" versions of their projects so any security issues in those branches result in the branch becoming unsupported. Maintainers initially agreed (as did users of their projects) that they would stop maintaining them as soon as Drupal 8 came out which could reasonably be predicted to be roughly 3 years in the future (Drupal 5 to 6 timeframe was 1 year, but it seemed like the release periods were getting longer).
Proposal: The Drupal 6 lifecycle should be extended by 3 months after the release of Drupal 8. This gives sufficient time for custom and contributed projects to be upgraded to Drupal 8 and for sites running on Drupal 6 to be upgraded without creating unreasonable burden on the Drupal Security Team or project maintainers. When Drupal 8 is released, we will work to explain what it means for the EOL of Drupal 6 as part of the release marketing around Drupal 8.
Comments
I wonder if there could be
I wonder if there could be some middle ground on security releases for Drupal 6 post Drupal 8 release. I think the majority of Drupal 6 sites that will be around 3 months, 12 months, or even 5 years after the Drupal 8 release will be simple ones. They won't be complex community sites or e-commerce sites, as those sites will have budgets for upgrades and complex module structures that cannot realistically be maintained for long.
Simple sites, on the other hand, won't need many updates. What if we attempted to support Drupal 6 core and modules from a minimalist perspective for the coming years? If a security patch is 'mitigated by the fact that you need X permission that no one would ever give to someone they don't trust,' then don't fix it. That covers most security updates.That way we could all focus on fixing security bugs that can be exploited by anonymous users. Those are the true threats to the simple, low budget Drupal 6 sites that will be around for years whether we like it or not.
I would counter that there
I would counter that there are just as many "complex community sites" that will be hesitant to upgrade because of the complexity of their sites. It is potentially a lot of work to go from 6 to 8 (or even 6 to 7) depending upon how the different APIs changed from version to version of the various contrib modules and core.
What if we look at the Microsoft example with Windows XP and try to follow a similar model. Something like this:
2a. Like Microsoft, Highly Critical vulnerabilities found in Drupal 6 could still receive patches at the discretion of the security team. These patches are not guaranteed, merely provided to protect the Drupal image (similar to what MS did with IE8 after XP was EOL).
Open questions/thoughts:
-In the above plan, do we ever need to stop publishing security advisories for D6? I don't know how much work it is on the security team to put together the announcements (assuming they don't need to coordinate fixes and releases) so I don't know how feasible the security advisories in perpetuity plan is. Part of me says that any vulnerabilities will likely become public knowledge anyway so why not keep them centralized in one place. On the other hand, if it is a huge burden on the security team to write/post them then maybe we should put an end date to it.
Ignoring who does the work,
Ignoring who does the work, here are the minimum set of steps to work on a new issue:
Each issue takes at least a few hours in the best case scenario.
Eliminating the patch and release node steps would leave a significant number of steps. I don't think it's reasonable to continuing accepting, confirming, writing advisories, and publishing advisories. Confirming issues often takes a significant effort on its own.
knaddison blog | Morris Animal Foundation
ecommerce
Based on the reported usage stats, I'm betting we'll have 10,000 D6 ubercart sites 12 months from now https://drupal.org/project/usage/ubercart. I'm not sure if that will change @ezra's recommendation.
As an early (earliest?)
As an early (earliest?) member of the community who supported the idea of extending Drupal 6 support, I've actually changed my mind. This is a big reason why I've been quiet since posting Drupal 6 end of life — or not? in March, 2013.
It would have been great if we'd figured out what to do with D6 support sooner, but now it's 14 months since that post. During that time more and more developers are abandoning their contrib modules and themes.
I originally felt that extending D6 core security support would be hugely beneficial to all the universities, non-profits, and mom and pop e-commerce shops running on shoestring budgets. There are also plenty of owners of complex D6 web apps out there who have already made large investments. Now I'm not so sure that extending D6 security support is worth it. I seriously doubt that given the choice these site owners would ever upgrade or even perform basic updates.
From what we've seen doing maintenance and support for customers, the vast majority of the Drupal security work we do includes the above maintenance and fixing custom code or "un-hacking" contrib modules our customers' previous developers have modified. We also maintain D6 versions of some modules that have been discontinued but that's another story.
The Drupal-ocalypse I described in Drupal 6 end of life — or not? is still something I lose sleep over. I can easily picture hundreds or thousands of D6 sites turned into bitcoin-mining zombies, which is obviously bad for site owners but arguably even worse PR for the Drupal project.
While extending security support for D6 core is probably well-intentioned, my bet is that it probably isn't the best use of the Drupal core maintainers' time. I see an announcement that we're extending D6 core security support being the perfect psychological bandage that gives site owners and their maintainers false comfort and another reason to delay the inevitable, which is to do a thorough security audit and implementation, upgrade to Drupal 7 or cross-grade to something else.
Now that it's 2014 I believe the best approach to D6 core and contrib security is to privatize it as much as possible. At Larks, we've been hiring more and more developers with web application security expertise. Rather than crowdfund like originally suggested at Drupal 6 end of life — or not?, we've created an internal budget for this, have our own security team, and are figuring out which individuals want to apply to join the Drupal security team.
As a community, we should make it easier for site owners and their maintainers to know which modules are really being actively maintained. The Update module does indicate when installed modules and themes have been discontinued (unpublished) but it gives users a false sense of security when everything shows green on the available updates page but it doesn't have a clue when modules or themes have been abandoned by their maintainers and they simply haven't updated their project pages.
It should continue to be supported
The trend should be broken in this case as Drupal 8 is too different from Drupal 7 and so upgrading from 6-> 8 will not be worth it for most site owners with extensive custom code. Drupal 6 is supported on a number of Drupal specific hosting options including Pantheon while currently Drupal 8 is not. All of the best modules on Drupal 6 have not even been ported to Drupal 7, let alone 8, while people (myself included) are actually working on backporting modules to 7 (hey people need it). The "Windows XP" analogy is a good one and could probably even be extended to include Windows 8. I would rather be using an updated version of Windows XP than Windows 8 myself.