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
Description
Related Objects
- Mentioned Here
- T101017: Early security release access for Lcawte (ShoutWiki)
T232113: Write and send supplementary release announcement for extensions with security patches (MediaWiki 1.31.4/1.32.4/1.33.1)
T133700: MobileFrontend contributions display edits where username is revdel'd without having appropriate rights
Event Timeline
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.
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.
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.
"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.
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
I've been sending supplemental security announcements for about a year and a half now with each quarterly-ish security release of core and bundled extensions/skins. This provides some... eventual visibility and disclosure for security issues related to non-bundled extensions and skins. There's also T101017, which the Security-Team had wanted to generalize to any user interested in such access (and not just the specific user within that task description), though that task has been de-prioritized for now. I would assume that if a general process is ever documented and implemented for T101017, that plus the continued supplemental announcements should likely be a good effort to better our security disclosures for non-bundled extensions and skins, though I think the Security-Team would be open to any other reasonable suggestions.