Page MenuHomePhabricator

Restrict editing of core MediaWiki javascript / css with a separate user right
Closed, DeclinedPublic

Description

Umherirrender added a patch, gerrit 154452, which adds a site js/css user right, similar to the right to edit user js/css (T10834).

I want to track this with a bug, so we can document the decision to implement this, if we decide to. I've thought about implementing this for a while, and I'm happy to see it done. I think this is an improvement in MediaWiki supporting least privilege / separation of duty.

In the last few weeks, there has been a lot of discussion about supporting a more formal code review process for site js/css (T71445). In my first look, I don't think Umherirrender's patch conflicts with this goal, but if it does, that would potentially be a reason to not merge it.

Other thoughts?


Version: 1.24rc
Severity: normal

Details

Reference
bz70182

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 3:37 AM
bzimport set Reference to bz70182.
bzimport added a subscriber: Unknown Object (MLST).

gerritadmin wrote:

Change 154452 had a related patch set uploaded by Ebe123:
Add 'editsitejs' and 'editsitecss' user rights

https://gerrit.wikimedia.org/r/154452

This is absolutely pointless while we have bug 43646 (and others like it but unreported - run a google search if you can't see that bug)

What about restricting the edit of raw messages to users with a "editrawmessages" user right in such a way that "editinterface" is not enough to edit them?

Well, if you want to go and identify all raw messages... If you missed one though, adding it to the list would probably be a security issue involving releases etc.

The patch is not a security patch, just a way to restrict the serious way to edit javascript. There are also other ways to disable (or try to disable) some html in messages, like spam filters or abuse filters.

(In reply to Alex Monk from comment #2)

This is absolutely pointless while we have bug 43646 (and others like it but
unreported - run a google search if you can't see that bug)

In addition to MediaWiki:Copyright (Sorry, not mentioning the issue when its so well known that we even have projects like enwikinews actually using it as a feature, seems silly to me), most projects have various random pages in the mediawiki namespace that get loaded from main js. Not to mention gadgets and things. There are lots of ways to get js into the site

Change 154452 abandoned by Umherirrender:
Add 'editsitejs' and 'editsitecss' user rights

Reason:
Thanks for the comments, but it seems that this will conflict with future concepts from the wikimedia foundation.

Bad for third party wikis, but okay.

https://gerrit.wikimedia.org/r/154452

matmarex set Security to None.
matmarex removed a subscriber: Unknown Object (MLST).

So, is the conclusion that this should be Declined?

Krinkle claimed this task.

With Gadgets going to their own namespace (and user right), I think it'd be interesting to finally look into separating/untangling content administration (deleting pages, blocking users) from site administration (maintenance of javascript and css programs).

Common.js/css is fairly trivially replaced by a gadget. However <skin>.js/css and Group-<id>.js/css are slightly less trivial. Though they could become predefined gadgets with custom load principles server-side as part of the Gadgets extension (behind a configuration flag).

At that point Gadgets (aside from user-individual scripts) would be a unified system for site scripts from which we can start implementing code review principles.

We can investigate later whether that system will be revision management (like FlaggedRevisions), or review-management (e.g. draft edit branches on a Special page, a bit like Git/Gerrit/GitHub), or off-wiki entirely by deferring it to an actual Git repository maintained by the community (using Gerrit/Github/Phrabricator/whatever as its review tool).

Tgr subscribed.

There has been no progress on Gadgets 2.0 in the half year since this bug has been closed, and probably won't be for a while. Limiting the ability of editing site scripts to those who actually need it is an obvious improvement to our current rather sad security situation; that it is not a perfect improvement is not a meaningful counterargument. Leaving the key under the doormat and leaving the front door wide open might both be insecure, but not equally so.

As far I see, having separate editsitejs/editsitecss rights (or a single editsitescripts - I don't think there is much need for keeping CSS/JS separate) would not conflict with a future gadgetization of site scripts - for now the right would be used to control editing of MediaWiki:*.js/MediaWiki:*.css, and after that it would control editing of the Gadgets: namespace, or maybe the marking of gadgets as global. Even if that's not the case and gadgets would use different or more granular rights, having these rights would pose no problems; it could just be deprecated or discarded at that point. Plus if gadgets do not become part of core, it would be still useful for wikis not using the extension.