@KylieTastic you can use the following patch demo url to test - https://47c28b4723.catalyst.wmcloud.org/w/ and login with username Patch Demo and password patchdemo1 to test. That user is an admin so you should be able to delete and undelete pages there.

@taavi you are right, the reauth work caused a regression. I hope that you can review my patch when you get a chance. @KylieTastic I know you said you don't have much PHP experience, but you are welcome to review and I can also create a patchdemo if you want to test the changes yourself.

In T433070#12366288, @Tacsipacsi wrote:

In T433070#12193532, @Mstyles wrote:

Deployed

Deploying it didn’t hurt, but I believe this piece of code isn’t enabled in WMF production at all, only on translatewiki.net and a tiny number of external MLEB users, if at all.

---

A few weeks ago, I started expanding API docs (I didn’t get to upload the patch yet), and stumbling upon this API endpoint, I was wondering if it should be split:

• do=create is to be called by the user to be sandboxed themselves (an unauthorized user) and uses the parameters username, password and email;
• do=delete, do=promote and do=remind are to be called by a translation admin (i.e. a user with the translate-sandboxmanage right) and use the parameter userid.

So do=create requires different authorization and (other than the do and token parameters) a disjoint parameter set. Splitting it off action=translatesandbox would allow moving the authorization for the remaining three actions to execute(), leaving less space for such security bugs, and it would also allow making parameters in both resulting endpoints required (which makes the endpoints easier to understand and requires fewer custom validation steps).

Alternatively, couldn’t do=create be removed and replaced with hooking into action=createaccount?

@sbassett I can confirm that the CSP is enforcing and has been deployed. I do plan to do some follow up analysis to see if there is anything we are still missing, but we can definitely resolve this.

Rebased patch that I will upload to the deploy server

@Samwalton9-WMF I would appreciate your review on this patch

In T433020#12224566, @Mstyles wrote:

Take 3 - I ran the query against the prod MariaDB replicas and didn't get any issues. I think that this patch is deployable

T433020-3.patch2 KBDownload

Resolving this task since this project ended last fiscal year

Take 3 - I ran the query against the prod MariaDB replicas and didn't get any issues. I think that this patch is deployable

In T433020#12218167, @Mstyles wrote:

T433020-2.patch2 KBDownload

The entire tag is still suppressed but the db approach now uses the existing pager SELECT query instead of per row.

In T434967#12218254, @SomeRandomDeveloper wrote:

T434967.patch1 KBDownload

The entire tag is still suppressed but the db approach now uses the existing pager SELECT query instead of per row.

In T434549#12203595, @Lucas_Werkmeister_WMDE wrote:

Suggested patch:

0001-SECURITY-HTML-escape-error-messages-in-Special-SetLa.patch3 KBDownload

In T434619#12205861, @SomeRandomDeveloper wrote:

I can reproduce this both with collection titles and album titles.

We can use .text() instead of .append(), as the two affected elements are newly created and don't have any contents yet:

T434619.patch1 KBDownload

In T433020#12213191, @sbassett wrote:

In T433020#12192903, @Mstyles wrote:

T433020.patch1 KBDownload

Just looking at the logic here, I think that db select runs on every reviewed history row, yes? I feel like that could get quite heavy on wikis with hundreds+ of reviewed rows. I think this is also a bit of a sledgehammer approach as it removes the entire tag, but that's probably fine.

In T433070#12193020, @Mstyles wrote:

Converted the diff to a patch for today's security deploy

T433070.patch1 KBDownload

Converted the diff to a patch for today's security deploy

I've tested this locally and it worked great. Would love some review so it can go out next Thursday (Monday is a holiday for WMF).

In T430601#12170708, @Jdforrester-WMF wrote:

This looks great; a minor whitespace fix just so that security patch we deploy and the one we land in git once it's in prod will be identical so the tooling agrees they're the same:

T430601-3.patch37 KBDownload

In T432877#12148230, @SomeRandomDeveloper wrote:

I think we can just escape the messages, as they don't contain any HTML:

T432877.patch1 KBDownload

Tested locally with the commit from T431236. Created a wikitext page in the MediaWiki namespace and used Special:ChangeContentModel to change it to javascript. Got the reauth prompt on submit, and after reauthenticating I landed on the success page without needing to re-fill the form. Confirmed via Special:PageInfo that the content model was updated.

In T407974#12121720, @SomeRandomDeveloper wrote:

T407974.patch5 KBDownload

In T432425#12138843, @SomeRandomDeveloper wrote:

In T432425#12137882, @Catrope wrote:

In T432425#12131150, @SomeRandomDeveloper wrote:

T432425.patch1 KBDownload

This patch looks fine, and can be deployed, but I don't think we need .parseDom() here, it can just be .escaped(). There's no advanced wikitext (links etc) in the message that require HTML output, it's just text with some {{GENDER:}} stuff.

Fixed in

T432425-02.patch1 KBDownload

In T432419#12131024, @SomeRandomDeveloper wrote:

T432419.patch1 KBDownload

AFAICT, centralnotice-geo-status and its parameters don't contain HTML, so we can escape the message.
I also don't think that option names are supposed to contain HTML here, so we can escape those as well. Technically, ui.multiselect.js is in the resources/vendor/ directory, but it was modified before and also uses MW-specific code like mw.message(), so I think it should be fine to change it.

In T432341#12128235, @SomeRandomDeveloper wrote:

T432341.patch974 BDownload

Generally it would be cleaner to just use a jQuery object for targetLink, but that would require making changes to unrelated code (I can upload a follow-up on gerrit after this patch is made public).

I uploaded a patch that shows a clearer error message from badaccess-cannotreauthenticate. The checkboxes are still hidden and there's no reauth link — I left it that way since submitting would fail anyway. Did we want to add checkboxes and a reauth link here or is handling of permission errors coming from T197136?

In T321092#12115358, @sbassett wrote:

In T321092#12109932, @SomeRandomDeveloper wrote:

Suggested patch:

T321092.patch1 KBDownload

CR+2. Thanks for picking this up. We can get this deployed today. I'm always re-reminded that ext:Collection is still deployed on most projects...

Marking this as resolved due to updated reauth process. Please file a new bug if there are issues with the new workflow

In T428006#12082596, @sbassett wrote:

Formalized my suggestion above into a patch:

01-T428006.patch1 KBDownload

I feel like this could probably just go through gerrit, tbh. It also only satisfies the condition where media/file backends (like Swift) support writing a content-type for a given asset. For plain installations of MediaWiki, this would still likely need to be managed at the web server layer.

Email from T411394#11796980 has been sent to various mailing lists:

• wikitech-l
• mediawiki-l
• mediawiki-announce

@SomeRandomDeveloper just got those as well