@Arian_Bozorg Can you please prioritize this for the EntitySchema work?

New patch with working tests (updated existing tests and added new ones; no changes outside the tests):

In T339016#8956002, @Lucas_Werkmeister_WMDE wrote:

New patch with working tests (updated existing tests and added new ones; no changes outside the tests):

0001-SECURITY-Run-EditFilterMergedContent-hook-on-edits.patch44 KBDownload

I reviewed the patch and both the production changes as well as the tests look alright. The tests are passing when I run them locally. I tried the change in my local installation with AbuseFilter too, and all possible edits are now indeed passed through AbuseFilter.

➡️ This has my +1 to apply the patch to production.

Deployment of this will have to wait until Wednesday (it’s not urgent enough to deploy on a Friday, and most Wikidata devs including myself will be at an offsite on Monday and Tuesday), but I’ve prepared AbuseFilter 20 on Test Wikidata, which blocks any edit adding the content !!!block this edit via AbuseFilter!!!; it should be possible to use that for testing the fix after deployment.

Deployed (I forgot last week, sorry). I tested the following four scenarios on Test Wikidata (using the aforementioned AbuseFilter):

• change existing schema’s label (Special:SetEntitySchemaLabelDescriptionAliases)
• change existing schema’s text (action=edit)
• create new schema with blocked text in label (Special:NewEntitySchema)
• create new schema with blocked text in text (Special:NewEntitySchema)

All four got blocked correctly (although, for Special:NewEntitySchema, with an internal error, as mentioned in the patch’s commit message – can be fixed later).

@Lucas_Werkmeister_WMDE and @Michael : we still have a security patch in production for EntitySchema. Looks like it got split in smaller bits:

1c91866 Require strict types in Domain
ccff6c9 Require strict types in MediaWiki
25ec145 Require strict types in MediaWiki/Actions
f1d801f Require strict types in MediaWiki/Specials
6e0c1ad Require strict types in MediaWiki/Content

Can you confirm? The file is /srv/patches/1.41.0-wmf.16/extensions/EntitySchema/01-T339016.patch and if it is obsolete we can git rm && git commit it on the deployment server to get rid of it :)

It is definitely not obsolete, those changes are unrelated, I didn’t realize they were touching the same files sorry. I’ll see if I can rebase the change later.

Okay, rebased change (there were only two smaller conflicts, which I resolved by picking the security change’s version and then manually adding the strict types back):

@jnuche - Is this still a deployment blocker given the rebased patch from T339016#8987240?

@sbassett not anymore. Removed from the list

@Lucas_Werkmeister_WMDE Can you look at /srv/patches/1.41.0-wmf.18/extensions/EntitySchema/01-T339016.patch on the deployment server and revise it so that it patches cleanly?

Rebased onto 1.41.0-wmf.18 because it conflicted with Require strict types in DataAccess (my own change – I didn’t realize it would conflict, my bad):

Also updated in /srv/patches.

Thanks you very much @Lucas_Werkmeister_WMDE for the quick fix!

@Lucas_Werkmeister_WMDE we have nightly job that cuts a branch from MW core and applies existing patches to verify their health. This patch failed to apply in last night's run: https://releases-jenkins.wikimedia.org/job/Branch%20cut%20pretest%20patches/35/console

It seems we don't have a public gerrit patch for this yet, can you rebase the existing patch to fix the conflict(s)?

Ah, I imagine this will be due to T332330: [ES-M5] Rename classes / files from Schema to EntitySchema. Where exactly should I rebase the patch? Just master? (AFAICT all of the renames got merged after the wmf.23 branch cut.)

Yeah, wmf.23 wasn't affected, so we just need to rebase on master

Patch rebased onto c60f597216:

@Lucas_Werkmeister_WMDE thank you!

@dancy I'm looking at how Scap applies the patches and it seem that, unless we modify the process somehow, we won't be able to apply the amended patch until we have prep'd the branch for wmf.24

On the other hand, if we tried to add the patch to the existing wmf.23 patches dir so it can be used by the nightly jobs, that would break current train and backports. But you know this process better and maybe you have some tricks up your sleeve?

In T339016#9113721, @jnuche wrote:

@dancy I'm looking at how Scap applies the patches and it seem that, unless we modify the process somehow, we won't be able to apply the amended patch until we have prep'd the branch for wmf.24

On the other hand, if we tried to add the patch to the existing wmf.23 patches dir so it can be used by the nightly jobs, that would break current train and backports. But you know this process better and maybe you have some tricks up your sleeve?

Can you not just manually create a wmf.24 dir under /srv/patches? We've definitely done that before. Unless there is now automation that prevents that from happening or being a good idea. In which case, I guess we should know about that.

In T339016#9114073, @sbassett wrote:

In T339016#9113721, @jnuche wrote:

@dancy I'm looking at how Scap applies the patches and it seem that, unless we modify the process somehow, we won't be able to apply the amended patch until we have prep'd the branch for wmf.24

On the other hand, if we tried to add the patch to the existing wmf.23 patches dir so it can be used by the nightly jobs, that would break current train and backports. But you know this process better and maybe you have some tricks up your sleeve?

Can you not just manually create a wmf.24 dir under /srv/patches? We've definitely done that before.

That is the right solution. Copy /srv/patches/1.41.0-wmf.23 to /srv/patches/1.41.0-wmf.24, make any required modifications under /srv/patches/1.41.0-wmf.24, and commit. The patch pretest will always use the newest directory under /srv/patches for testing.

Unless there is now automation that prevents that from happening or being a good idea. In which case, I guess we should know about that.

Nope. Nothing preventing that at this time.

That is the right solution. Copy /srv/patches/1.41.0-wmf.23 to /srv/patches/1.41.0-wmf.24, make any required modifications under /srv/patches/1.41.0-wmf.24, and commit. The patch pretest will always use the newest directory under /srv/patches for testing.

I've copied manually all the patches to 1.41.0-wmf.24 and replaced the existing EntitySchema patch with the new one Lucas rebased on master. We should see the job recover tonight.

Thank you all!

Rebased again onto 94ccb9fade:

I’ve also updated /srv/patches on deploy1002. (Another rebase might be necessary tomorrow after this change gets merged.)

Rebased again onto 477ca3c4de:

I also updated /srv/patches again. I hope this will be the last rebase for now – we don’t have any other classes left in T332330.

Thanks @Lucas_Werkmeister_WMDE