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.
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.