Page MenuHomePhabricator

Formalize procedures for doing security releases of MediaWiki extensions
Open, MediumPublic

Description

Ryan Lane has voiced criticism on wikitech-l on the handling of T133700 ( https://lists.wikimedia.org/pipermail/wikitech-l/2016-April/085415.html ). Regardless of if you agree with his critique or not, it appears we don't have any formal procedures for how security releases of WMF-maintained but not mediawiki-bundled extensions are done. It would probably be good to have official procedures for this sort of thing written up

Event Timeline

Bawolff created this task.Apr 26 2016, 7:35 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 26 2016, 7:35 PM

I'd be minded to Decline this task.

By long-standing direction from the Board, WMF isn't funded to make nice software for third parties except to the extent that it's beneficial to the Wikimedia wikis (e.g. by encouraging more usage, new ideas, additional expertise, etc.).

The exception made for MediaWiki itself, and a few bundled-with-core extensions, is us being 'nice', and comes at a very significant cost in terms of labour (mostly by @csteipp and @demon, but others help a great deal). Adding this to the budget for each of the ~200 extensions running in WMF production would be excessive.

However, based on my experience with these "WMF should do third party support" tickets in the past, it'll be accepted, I'll be shouted down, and then it'll just be quietly ignored for the vast majority of cases anyway, leaving third parties with false impressions. :-(

That's also an acceptable solution, but if that's the case then Wikimedia Foundation should update the wiki page for their extensions saying that they aren't fit for third party use.

demon added a comment.Apr 26 2016, 8:28 PM

That's also an acceptable solution, but if that's the case then Wikimedia Foundation should update the wiki page for their extensions saying that they aren't fit for third party use.

I would argue that most extensions fit this bill, WMF-deployed or not 😂

I'd be minded to Decline this task.
By long-standing direction from the Board, WMF isn't funded to make nice software for third parties except to the extent that it's beneficial to the Wikimedia wikis (e.g. by encouraging more usage, new ideas, additional expertise, etc.).

This bug isnt about doing or not doing anything in particular (in regards to sec rel of ext). Its about deciding what we will do, and writing it down.

The exception made for MediaWiki itself, and a few bundled-with-core extensions, is us being 'nice', and comes at a very significant cost in terms of labour (mostly by @csteipp and @demon, but others help a great deal). Adding this to the budget for each of the ~200 extensions running in WMF production would be excessive

This is a straw man, given most of those extensions have never needed a security release in their entire history.

Additionally, nobody is saying the procedures have to be the same as for mediawiki core. In fact id say having the same procedure would be overkill.

However, based on my experience with these "WMF should do third party support" tickets in the past, it'll be accepted, I'll be shouted down, and then it'll just be quietly ignored for the vast majority of cases anyway, leaving third parties with false impressions. :-(

Giving realistic expectations is the point of this bug. The bug asks to decide and document, not necessarily change procedure.

Legoktm added a subscriber: Legoktm.
ashley added a subscriber: ashley.Apr 26 2016, 10:13 PM

I support this :)

For my part, I'll try to document the desired security-bug process for bundled and WMF run extensions. I think there's enough community support (currently, but that's another topic) that we can have a decent process, regardless of whether the WMF funds it or not.

By long-standing direction from the Board, WMF isn't funded to make nice software for third parties except to the extent that it's beneficial to the Wikimedia wikis (e.g. by encouraging more usage, new ideas, additional expertise, etc.).

"Long-standing direction"? I'd like to know where and when any permutation of the Wikimedia Foundation Board of Trustees even hinted at what you're saying and suggesting in this task.

This document was unanimously approved by the Board you're referring to: https://wikimediafoundation.org/wiki/Resolution:Wikimedia_Foundation_Guiding_Principles#Freedom_and_open_source. Quoting it:

All software code written by the Wikimedia Foundation is licensed under an applicable free software license. We realize our obligations not just to share code, but to cultivate a healthy community of contributors around the source code, and to work with upstream projects and contribute back improvements to their code.

Regarding the impetus for this task being filed, the MobileFrontend extension is unequivocally and unambiguously a product of the Wikimedia Foundation.

Part of the open source social covenant is being a responsible maintainer of your products. Asking that extensions have a clear versioning system that allows users to know whether they're running your bad code or your slightly less bad code is completely reasonable.

demon removed a subscriber: demon.Feb 19 2019, 10:26 AM
Jcross triaged this task as Medium priority.Oct 4 2019, 4:52 PM
Jcross added a subscriber: Jcross.Oct 4 2019, 4:57 PM

As an initial approach to get better visibility around security issues for bundled and deployed extensions, we plan to send this supplementary announcement: https://phabricator.wikimedia.org/T232113

chasemp moved this task from Incoming to Back Orders on the Security-Team board.Dec 2 2019, 8:52 PM