potentional security vulnerability

So...here is the story:

Title::getRestrictionTypes() calls TitleGetRestrictionTypes hook, which is received by Wikibase\Repo\RepoHooks::onTitleGetRestrictionTypes, which has the following codepart:

if ( $namespaceLookup->isEntityNamespace( $title->getNamespace() ) ) {
	// Remove create and move protection for Wikibase namespaces
	$types = array_diff( $types, [ 'create', 'move' ] );
}

It seems it wrongfully considers Commons's main namespace as namespace for instances, which doesn't have move protection allowed. Unlike Wikidata, Commons's main namespace isn't reserved for Q items and can be actually move protected.

Tagging relevant projects to have a look.

@Ladsgroup Could you please help to triage this from the Wikibase side? Thanks!

Hey, Adding PMs of SDC and Wikidata. This seems severe.

adding Tonina as the coming week's incident manager and Adam to have it on his radar. We need to get this fixed.

Wikimedia Commons & Wikidata example

The following example shows Wikimedia Commons using entities from Wikidata.org:

$entitySources = [
    'wikidata' => [
        'entityNamespaces' => [
            'item' => 0,
            'property' => 120,
            'lexeme' => 146,
        ],
        'repoDatabase' => 'wikidatawiki',
        'baseUri' => 'http://www.wikidata.org/entity/',
        'rdfNodeNamespacePrefix' => 'wd',
        'rdfPredicateNamespacePrefix' => '',
        'interwikiPrefix' => 'd',
    ],
    'commons' => [
        'entityNamespaces' => [
            'mediainfo' => '6/mediainfo',
        ],
        'repoDatabase' => 'commonswiki',
        'baseUri' => 'https://commons.wikimedia.org/wiki/Special:EntityData/',
        'rdfNodeNamespacePrefix' => 'sdc',
        'rdfPredicateNamespacePrefix' => 'sdc',
        'interwikiPrefix' => 'c',
    ],
];
$wgWBRepoSettings['entitySources'] = $entitySources;
$wgWBClientSettings['entitySources'] = $entitySources;

Further things to check/investigate/understand:

• is it possible to protect a page in any non-entity namespace in a repo against moving? E.g. can one actually protect https://www.wikidata.org/wiki/Wikidata:Sandbox against moving?
• is it possible to protect a page in the main namespace in a local repo/wiki where items are not in the main namespace against moving?

@Michael

is it possible to protect a page in any non-entity namespace in a repo against moving? E.g. can one actually protect https://www.wikidata.org/wiki/Wikidata:Sandbox against moving?

Tried that at https://test.wikidata.org/wiki/Wikidata:Sandbox, managed to successfully do so (verified via my WMF account, which has no advanced rights).

is it possible to protect a page in the main namespace in a local repo/wiki where items are not in the main namespace against moving?

No, it isn't possible to move-protect pages in main namespace, even when items aren't in the main namespace. For me, the protection interface looks like this:

instead of something like this:

which is from my user sandbox page (in NS_USER).

@Michael To avoid confusion, the interface doesn't have any option for move-protection for pages in NS_MAIN at commonswiki - the main page appears to be move-protected only because it was already move-protected before this bug was introduced.

In T258323#6316964, @Urbanecm wrote:

So...here is the story:

Title::getRestrictionTypes() calls TitleGetRestrictionTypes hook, which is received by Wikibase\Repo\RepoHooks::onTitleGetRestrictionTypes, which has the following codepart:

if ( $namespaceLookup->isEntityNamespace( $title->getNamespace() ) ) {
	// Remove create and move protection for Wikibase namespaces
	$types = array_diff( $types, [ 'create', 'move' ] );
}

It seems it wrongfully considers Commons's main namespace as namespace for instances, which doesn't have move protection allowed.

Just to confirm – yes, it indeed considers ns0 as an entity namespace:

lucaswerkmeister-wmde@mwdebug1002:~$ mwscript shell.php commonswiki
Psy Shell v0.10.4 (PHP 7.2.31-1+0~20200514.41+debian9~1.gbpe2a56b+wmf1 — cli) by Justin Hileman
>>> use \Wikibase\Repo\WikibaseRepo;
>>> $namespaceLookup = WikibaseRepo::getDefaultInstance()->getEntityNamespaceLookup();
=> Wikibase\Lib\Store\EntityNamespaceLookup {#527}
>>> $namespaceLookup->isEntityNamespace( 0 );
=> true

NS_FILE, on the other hand, is not considered an entity namespace:

>>> $namespaceLookup->isEntityNamespace( NS_FILE )
=> false

But ns120 (Property on Wikidata) is considered an entity namespace:

>>> $namespaceLookup->isEntityNamespace( 120 )
=> true

On Commons, that namespace doesn’t even exist.

Looks like this relates to T205268: Many services in GenericServices are not actually that generic.

/me impersonates gerritbot

Change 616109 had a related patch set uploaded (by Itamar Givon; owner: Itamar Givon):
[mediawiki/extensions/Wikibase@master] Prevent onTitleGetRestrictionTypes changing ns0 protections

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

That change should fix the issue (and I think it’s okay that it’s public, it doesn’t make this issue obvious). Is this serious enough to justify a Friday deployment, or should we wait until Monday to backport it?

Change 616032 had a related patch set uploaded (by Itamar Givon; owner: Lucas Werkmeister):
[mediawiki/extensions/Wikibase@wmf/1.36.0-wmf.1] Prevent onTitleGetRestrictionTypes changing ns0 protections

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

Seems serious enough for a Friday deployment, Amir will deploy that backport once CI is done.

We got this deployed and it seems it fixes the issue, I monitor logs for any errors in the next couple of days.

/me impersonates stashbot (edit: sorry, hadn’t seen greg’s comment yet)

Mentioned in SAL (#wikimedia-cloud) [2020-07-24T16:47Z] <ladsgroup@deploy1001> Synchronized php-1.36.0-wmf.1/extensions/Wikibase/repo/includes/WikibaseRepo.php: [[gerrit:616032|Prevent onTitleGetRestrictionTypes changing ns0 protections]], Part I (duration: 01m 06s)

Mentioned in SAL (#wikimedia-cloud) [2020-07-24T16:49Z] <ladsgroup@deploy1001> Synchronized php-1.36.0-wmf.1/extensions/Wikibase/repo/includes/RepoHooks.php: [[gerrit:616032|Prevent onTitleGetRestrictionTypes changing ns0 protections]], Part II (duration: 01m 07s)

Seems to be fixed on Commons now (trying to move Hauptseite shows an error again).

Backported to 1.35: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/616033

Horray, I can move-protect commons pages too!

I'm also able to protect non-existent pages against creation:

I'm also not able to do the same at Wikidata.

Thanks everyone!

I think this can go public now. @sbassett @Ladsgroup @Addshore Opinions on that?

Once done, this should go to User-notice I think.

In T258323#6334048, @Urbanecm wrote:

I think this can go public now. @sbassett @Ladsgroup @Addshore Opinions on that?

Yep, everything important already went through gerrit. And I'm not seeing anything sensitive on this task that still requires protection.

Once done, this should go to User-notice I think.

Probably a good idea. At least some sort of public issue summary (besides this task) is likely warranted.

There was a restricted task merged into this. Should it be made public as well? (https://phabricator.wikimedia.org/T258323#6317139)

In T258323#6334121, @RhinosF1 wrote:

There was a restricted task merged into this. Should it be made public as well? (https://phabricator.wikimedia.org/T258323#6317139)

Done.

In T258323#6334151, @sbassett wrote:

In T258323#6334121, @RhinosF1 wrote:

There was a restricted task merged into this. Should it be made public as well? (https://phabricator.wikimedia.org/T258323#6317139)

Done.

Thanks!

Is this intended to be summarized in TechNews this week? If so, could someone please write a short (1-2 sentence) clear summary for inclusion? Thanks.

Suggested summary:

A bug in the Wikibase extension inadvertently disabled the “move” and “create” protection types in the main (Gallery) namespace on Wikimedia Commons. New protections could not be added, and existing protections were not enforced, allowing some page moves and creations that should not have been possible.