Page MenuHomePhabricator

Backport security fixes to stable + LTS [non-bundled] extension branches
Open, LowPublic


It seems we currently make no effort to backport security fixes in extensions, so anyone using a supported MediaWiki release will get security updates for core but not for their extensions. This seems pretty bad and should be either fixed or some sort or warning mechanism should be set up so someone downloading a nominally supported extension version can get notified that it contains a security hole. Or at the very least we should put a very clear warning on the version support documentation page saying that there is no support whatsoever for extensions (Version_lifecycle#Extension_lifecycle_management kind of suggests the opposite now).

Event Timeline

Tgr created this task.Aug 11 2015, 8:30 PM
Tgr raised the priority of this task from to Needs Triage.
Tgr updated the task description. (Show Details)
Tgr added a project: Security-Extensions.
Tgr added a subscriber: Tgr.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 11 2015, 8:30 PM
greg added a subscriber: greg.Jan 6 2016, 6:36 PM

Are you sure that there is "no effort" to backport security fixes to release branches of extensions?

Restricted Application added a subscriber: StudiesWorld. · View Herald TranscriptJan 6 2016, 6:36 PM
Tgr added a comment.Jan 8 2016, 8:15 AM

Uh... sorry, I probably had something specific in mind but I can't remember at all now what it was. Would sure have been nice if I had put it into the task description... please amend / close as invalid, if it's partially/completely wrong.

greg added a comment.Jan 8 2016, 6:53 PM

Yeah, I think there was some other context that we're forgetting, let's leave it open for a bit and hopefully we'll remember :)

demon added a subscriber: demon.Jan 8 2016, 7:37 PM

The context so far has basically been that we don't worry about backporting if it's not a bundled extension. That should/could change though.

@dpatrick is there somewhere we should document a change like this so that we remember to do it in the future?

@greg No, not that I know of. Perhaps at (which is out of date) or on some coding guidelines document on wikitech.

I have a couple of thoughts related to this. Ideally the backporting would be done by the person(s) submitting the patch for the fix, and the backport(s) should be required to be available at the same time as the original patch. This will make the security release process smoother.

greg added a comment.Jun 14 2016, 8:08 PM


I'll let @dpatrick close/rework this into other work he has going on (no rush).

demon triaged this task as Low priority.Jan 12 2018, 10:48 PM

Ive always tried to ensure fixes are backported for extension fixes im involved with, but we probably need to do better.

The story around extension security fixes in general is not great. No version numbers, no announcement list, no central list of fixed vulnerabilities.

Aklapper renamed this task from Backport security fixes to stable + LTS extension branches to Backport security fixes to stable + LTS [non-bundled] extension branches.Jun 29 2018, 3:02 PM
Osnard added a comment.Jul 2 2018, 6:55 AM

As a maintainer of a MediaWiki distribution this is a very important topic to me. When I compile a distribution package I only use LTS branches of MediaWiki and extensions/skins (as log as they are available). The bundles extensions/skins are always at an up-to date state (good job!), but a lot of other extensions do not properly support the LTS branches. For non-bundled-WMF extensions (like "Echo") I always had the feeling that they are also supporting LTS branches. Most other extension developers seem not to follow this approach. Maybe WMF could start an initiative to encourage extension developers to at least maintain LTS branches. In own extensions I actually delete all branches that are not actively supported.