I think this can be closed in favor of the more specific T200176: Deletion of user js and css requires deletion and edituser* rights. Or am I misunderstanding what you are asking for?

This seems to be something of the opposite of T200176. This task is identifying certain operations that should require both interface-admin and sysop, while that is complaining about one particular operation that does do so.

I tested these on my local dev wiki using a few pages:

• MediaWiki:Common.js
• MediaWiki:Foobar which was edited to have a JavaScript content model
• MediaWiki:Foobar.js which was edited to have a wikitext content model
• MediaWiki:Foobaz which has the default wikitext content model

In T201052#4473419, @PerfektesChaos wrote:

• undelete a *.js or *.css or reciprocal content model

Special:Undelete would not allow undeleting MediaWiki:Common.js at all. It would not allow undeleting MediaWiki:Foobar when the page existed, but would allow undeleting when the page didn't exist even though the top undeleted revision had the JS content model.

• deleterevision for such page (to restore)
• suppressrevision for such page (to make visible again)

These did not require the editsitejs or similar right at all. I don't see why they would need to, since you can't hide or unhide the text of the top revision anyway.

• import / importupload a *.js or *.css

These worked much like undeletion: import to MediaWiki:Common-imported.js was blocked, while import to MediaWiki:Foobar-imported succeeded when that page did not exist and failed when it existed with a JS content model.

• move into a *.js or *.css “page name extension”

I was unable to move MediaWiki:Foobar or MediaWiki:Common.js. I was also unable to move MediaWiki:Foobaz to MediaWiki:Foobaz.js.

• editcontentmodel from or to javascript / css

This failed to change MediaWiki:Foobar to the wikitext content model, and failed to change MediaWiki:Foobaz to the JS content model.

• delete such page

Deletion of MediaWiki:Common.js and MediaWiki:Foobar was not allowed.

• move into unrestricted namespace or page name

Moving from MediaWiki:Foobaz to MediaWiki:Foobaz2 was allowed. As noted above, moving a restricted page failed even when the target was not restricted.

• deleterevision for such page when hiding
• suppressrevision for such page when hiding (OS)

I didn't test these, since the new rights weren't required even for "restricted" pages.

In T201052#4479801, @Tgr wrote:

I think this can be closed in favor of the more specific T200176: Deletion of user js and css requires deletion and edituser* rights. Or am I misunderstanding what you are asking for?

I am afraid, yes. This task has a much broader scope.

Imagine there is a hijacked sysop account which attempts to bypass the mechanisms, heading for activating malicious code, but without editsite* privilege (and edituser* as well, but limited audience).

This epic is about to seal the current leakages, if any.

Arrival

We are used to edit and create a code page.

Other ways to place a page version are:

• move into restricted area
• undelete
• deleterevision (to restore)
• suppressrevision (to make visible again)
• import / importupload

That offers bypassing the straight way.

A page may have been deleted, since malicious code was detected. That is useless if it can be undeleted the next day by any sysop.

Vulnerable pages

In the related namespaces any page with the following qualities needs protection:

1. Page name ending on *.js *.css *.JS *.jS etc.
2. Content model CSS/JS.

Some wiki software might be persuaded to deliver such code into client, even if actually not supposed to. At least it is confusing and error-prone if vulnerable resources might be active or not when the behaviour is not obvious. In doubt it is regarded as a critical page.

Moving a page that it matches the first condition or changing the content model towards the second condition requires interface-admin privilege.

Removing

If a page contains bad things that has to be discarded immediately.

• sysop is sufficient for deletion.
• The same goes for deleterevision and suppressrevision (OS) when hiding.
• No obstacle must prevent a quick reaction.
• A privacy violation or detected malicious code must not wait until a global person is convinced to react, broken English stumbled perfectly. Any close local sysop shall help.

Moving a page outside the critical namespace or naming does not require special privileges. Making bad things disappear ASAP is improving security.

In T200176 deletion has to be granted.

Versioning

This is a tricky thing.

• Imagine a security leak has been found in page MediWiki:useful.js (revision 123) last year.
• That was remedied soon by revision 456.
• Now our attacker wants to re-activate the old version, which he might have originated himself.
• Just deleterevision 456 and 123 is active again.

That scenario is contradicting the request that bad things must be hidden immediately. There is no software solution, since it has to be judged which version is the toxic one and which is harmless.

This can be solved by T200766 Public monitoring of JS/CSS edits only.

@Anomie thanks for the detailed testing!

I think this behavior is as expected, except for:

but would allow undeleting when the page didn't exist even though the top undeleted revision had the JS content model.
[import/importupload] worked much like undeletion: import to MediaWiki:Common-imported.js was blocked, while import to MediaWiki:Foobar-imported succeeded when that page did not exist and failed when it existed with a JS content model.

These run permission checks before recreating the page so Title uses the default content model instead of the not-yet-existing content model. Filed as T202900: Content model based permission checks do not use the actual content model on undelete/import but seems cumbersome to fix and relatively harmless.

In https://en.wikipedia.org/wiki/Special:Diff/891619141, Xaosflux said that interface-admin is not needed to import a user script - can someone with the requisite rights check if this is still the case?

Yes, as mentioned in T190015, import does not check page permissions.

Also full protected templatestyles pages can not by edited by interface-editor.

Neither admin nor interface-admin can delete MediaWiki:*.js. Person who can delete must have delete and editsitejs rights to do this. Neither admin nor interface-admin have these two rightstogather.

In T201052#9154201, @hubaishan wrote:

Also full protected templatestyles pages can not by edited by interface-editor.

TemplateStyles doesn't have anything to do with the interface-editor or interface-admin groups, since pages with the sanitized-css content model are not security-sensitive.

Neither admin nor interface-admin can delete MediaWiki:*.js. Person who can delete must have delete and editsitejs rights to do this. Neither admin nor interface-admin have these two rightstogather.

I suppose security-wise there is not much harm in admins being able to delete a page that they (for good reasons) aren't able to edit or create.

I suppose security-wise there is not much harm in admins being able to delete a page that they (for good reasons) aren't able to edit or create.

And this is intended: If there is malicious JS etc., every sysop can delete such a page immediately, without asking stewards etc. for further help.