Developer Wishlist/2017/Extensions

Problem
There are a lot of extension using the userCan hook for access control. Yet there are still parts of the core where userCan is not considered. This is true in particular for read access. For example, afaik, QueryPages do not consider read access. Quite often, this is as simple as adding a userCan hook call. I'm not proposing to make Mediawiki read access bullet proof, but to fix the most obvious read access holes.

Who would benefit
Extension developers who need to implement access control for their mediawikis

Proposed solution
We can use this list as a basis: https://www.mediawiki.org/wiki/Security_issues_with_authorization_extensions. It needs to be updated to the current state of MediaWiki. Then the open questions / issues can be addressed in the code. Ideally, at the end we have a positive list of which pages / actions consider read access.

Support (T156788)

 * 1) Info-farmer (talk) 05:34, 6 February 2017 (UTC)

Problem
MediaWiki has a LTS release, which receives security updates. Unfortunately most extensions are being developed in current  or maybe latest   branch. That means that downloading an extension from  branch (e.g. by using Special:ExtensionDistributor) leaves the user with an outdated and potentially insecure codebase.

Who would benefit
Everyone who wants to use LTS version of MediaWiki and also be sure extensions that work with this version don't have security issues or severe bugs

Proposed solution
At least the greater WMF extensions like "WikiEditor", "VisualEditor/Parsoid", "FlaggedRevs", "CategoryTree", ... should get bugfix and security cherry-picks/backports from the current development into.

Of course most voluntary, WMF-independent extension developers won't have time/will to do something like this, but maybe we can find a way to help them or at least make them more aware of the LTS release.

Problem
There are some extensions (e.g. Extension:Math) that create files dynamically and then deliver those files to the user. Most extensions just create their files somewhere in, assuming that the location is accessible from the web. On private wikis this might not be true. Instead of direct delivery by the webserver the  might be invoked. Unfortunately the current implementation sometimes makes it difficult or impossible to deliver files that are not part of the local filerepo.

Who would benefit
Any extension developer that wants to create files (images, pdfs, JNLP, xml, flat files, ...) dynamically and deliver them by a script entry point.

Proposed solution

 * could be improved (see also T153174: img_auth.php: Improve extendability)
 * A complete new entry point could be created
 * Some mechanism besides filerepo/filebackend could be created that allows better management (save/cache, delete/invalidate, find) of files created by extensions

Implement addition of un-redirected pages to Special:NewPages and Special:NewPagesFeed
Per consensus here, en-wiki's Samwalton9 activated the relevant abuse filter on March 7th. After monitoring the filter log for a week, we are satisfied that the behavior is ready to be implemented on Special:NewPages and Special:NewPagesFeed, with two caveats:


 * 1) Edits that revert  a redirect to a prior state with content should not appear on these patrol pages.
 * 2) Pages where a redirect has been restored should disappear from the patrol pages, by analogy with new pages that have been deleted.

It's our understanding that this behavior can be implemented in the PageCuration extension. Thanks!

Support (T92621)

 * 1) Iazyges (talk) 05:22, 6 February 2017 (UTC)

CodeEditor: Migrate from Ace to CodeMirror
Has more features, is lighter(?) and has much better support for Unicode / BiDi text rendering (see http://codemirror.net/demo/bidi.html).

Plus Brion likes it :)

-- Version: unspecified Severity: enhancement

Support (T50826)

 * 1) Info-farmer (talk) 05:33, 6 February 2017 (UTC)

Remove all PHP entry points from all Wikimedia-deployed extensions and skins
Once all Wikimedia-deployed extensions and skins have been switched over to extension registration, and Wikimedia production has switched over to using them, we should remove the backwards-compatibility shims that very often imply support which doesn't exist for older versions of MediaWiki.