WordPress Security Team Discusses Backporting Security Releases to Fewer Versions

The WordPress Security Team is exploring different approaches to backporting security fixes to older versions of the software. The effort that goes into supporting versions back to 3.7 (the release that introduced automatic background updates) increases with each major version released.

“For the Core Security team, that means when security updates need to be released, we have to take the testing and release process not just to the current version of WordPress, but we have to test the changes, create code patches, and then release to every major version all the way back to 3.7,” security team lead Jake Spurlock said. “With 5.3 around the corner that puts us at over fifteen major versions of WordPress to support long term.”

Spurlock said 3.7 represents 0.1% of all WordPress sites but noted that supporting older versions requires “a large amount of time and energy and hurts the team’s ability to work effectively.”

When asked how much of a time investment is in involved, Spurlock said it varies depending how many tickets/issues have to be ported. All patches are reviewed, tested, and committed by several team members. There are approximately 50 security experts on the team, many of which are employed by Automattic, although some are volunteers.

“The problem with developing security releases for older versions of WordPress lies in the amount of testing and then reengineering that is specific to each older version of WordPress,” Spurlock said. “As an example. WordPress 4.2 received a fairly large refactor, and so taking a fix back before that time means extra testing, and ensuring that paths works for patches and more. Getting the testing suite to work on older versions has been difficult too with the code changes that accompany each version.”

Spurlock called for feedback and ideas on how the security team can support fewer versions of WordPress while keeping users secure. An active discussion is underway and opinions range from enthusiastic support for the idea to opposition.

Some who weighed in prefer to focus on urging users to update via emails to admins on older installs and/or a “please upgrade” widget ported back to older versions. As big version jumps can be intimidating for users, some recommended WordPress provide better ways to do incremental updates from older versions to the next most recent.

“If the goal is to keep WordPress users secure against hackers and other rogue agents, you should continue supporting older versions with security releases,” WordPress core contributor Rami Yushuvaev said.

“WordPress 3.7 represents 0.1% of all WordPress sites but WordPress 3.0 – 3.6 represents 1.6% of all WordPress sites. You don’t want to increase the number of sites using un-secure versions. With the current policy, ‘old version’ is not the same as ‘un-secure version.’

“I think you should educate users to use updated software, not to stop releasing security releases for older versions.”

Several commenters are in favor of limiting backporting security fixes to a set number of versions, as outlined by former WordPress security lead, Aaron Campbell:

I like the idea if supporting X versions back. That allows users to know that they don’t have to update to the latest version no matter what our release cycles are, and also makes sure we can eventually hone in on how many versions are actually tenable to support.

Supporting X years back would allow users to know they can avoid upgrading for a certain amount of time, but it would also mean that the security team wouldn’t always be supporting the same number of versions and if a release ever took longer than our supported time then all users would be expected to upgrade to the latest version (exceptions could always be made, but it’s harder to rely on those).

Stephen Edgar, one of the maintainers of WordPress’ build tools component, suggested implementing automatic major version upgrades to keep moving users forward to supported versions in waves.

“Maybe continue to ship them until ‘major’ updates are implemented,” Edgar said. “The current thinking is to add major updates to 3.7 first, bumping 3.7 to 3.8 via automatic updates. Once that’s completed then security updates would no longer be backported to the 3.7 branch.

“And similarly, once 3.8 major updates are implemented, i.e. 3.8 gets bumped to x.x then again, backports to 3.8 would cease at the same time and so forth through the branches.”

Edgar also noted that providing users a way to opt into automatic updates for major core releases is one of the nine projects that Matt Mullenweg had identified for working on in 2019.

Several other commenters said they would like to see WordPress implement semantic versioning and adopt a long-term support (LTS) policy. WordPress would then clearly communicate the number of years those versions would be supported. Older sites could then be auto-updated to the LTS version.

No decision has been made on the ideas proposed and the discussion is still ongoing. If you have experience maintaining older sites or have input on how WordPress can best keep users secure while decreasing the work load, leave a comment on the Make WordPress Core post.

Would you like to write for WP Tavern? We are always accepting guest posts from the community and are looking for new contributors. Get in touch with us and let's discuss your ideas.

7 Comments


  1. Ultimately, it’s not the WordPress Team who is responsible for the security of users’ websites. The users are. The team’s resources are better spent focused on making the current releases as secure as possible in the face of increasing, more complex threats.

    Stop coddling users who don’t keep up with upgrades.

    There’s no defendable excuse.

    Report

    Reply

  2. This is a good move if you’re going to be running an obsolete version of the software you know you run the risk of being vulnerable to exploits. You don’t complain to Microsoft that your Windows XP PC has been hacked when they stopped supporting it years ago.

    It’s a waste of the teams time to continuously support an obsolete version of WordPress.

    Report

    Reply

  3. I think there should be timeframe (eg 2 years) and all versions released within that timeframe get a patch.
    Also an option to update to another version than the most current might help users

    Report

    Reply

  4. One of the few remaining good things of WP, that you know you’ll get security updates, and JUST security updates, no feature changes, and be able to stick to the version you’re comfortable with, for whatever reason. Get rid of this and… Not that it’d be unexpected, with the way it’s been going for years now.
    Also, never EVER force updates automatically. And yes, people do also complain about MS ending support, and forcing updates.
    Now LTS versions could be a compromise, but it’d still be way worse than what we have now, and they’d have to be selected very carefully, have one before each significant change, so if there were 2 or more major versions in a row that were major in name only, without significant changes, you could perhaps only continue to support the last, but that’s about it. And again, even then it’d be worse that now.
    And overall, I still say that for most purposes I’d much rather have just that when it comes to software, a version I decided suited me at some point and is kept stable and secure, with devs focusing on polishing and hardening more than on the next thing all the time. And do believe that many, likely most, who just want to get something done, use software for a particular purpose (even personal purpose, I mean, not just business environments, where stability really is key), would prefer the same.

    Report

    Reply

    1. This seems to be cross-posted from the comments on make/core, so I figured I’d cross-post my reply as well.

      The problem is that we don’t have the people power to continue to support all the currently supported versions (16!), and since we want the software to keep moving forward and improving, that number will continue to grow. If we don’t change the versions we support and reduce the load in that way, we still have to solve the problem in some other way.

      A team of people hired by some person or company to handle backports for these older versions would be another potential way to solve the problem I suppose, but I can’t think of any person or company that would want to invest that kind of money into keeping up old versions of WordPress (that doesn’t mean they don’t exist, but I can’t think of any).

      Report

      Reply

      1. Yeah, was kind of interesting to dig into a little bit of research around this. There are agencies that have developed LTS versions of Drupal and Magento, but using that software comes with support fees to pay for the active development of these older pieces of software.

        I think that for the most part, people that are staked to older versions of WordPress are doing it intentionally and if auto-updates were introduced would bypass them.

        Doing major before the auto-updater was terrifying, and I know that I overwrote my wp-content folder when I was getting started a million years ago… 😬

        Report


  5. This isn’t the first time this issue has come up. WordPress 2.0 was meant to be a long term stable version, but support for that ended up being dropped before it was even officially stated until. At that time, it appeared (to me) that there would be no backported security fixes available in future at all.

    If the team wants to continue providing this backwards compatibility, then perhaps it should just be stipulated that it’s only for one or two point releases backwards. If someone can’t upgrade in six months, then they probably never will. You can’t keep backporting fixes eternally; it’s an ever growing number of versions to support.

    Report

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.