Change 759704 had a related patch set uploaded (by Stang; author: Stang):

[operations/mediawiki-config@master] Update $wgCrossSiteAJAXdomains

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

Change 759739 had a related patch set uploaded (by Stang; author: Stang):

[operations/mediawiki-config@master] Update $wgCrossSiteAJAXdomains

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

Change 759704 abandoned by Stang:

[operations/mediawiki-config@master] Update $wgCrossSiteAJAXdomains

Reason:

another patch at r759739

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

Security-Team will leave a comment on the change set.

Change 759739 merged by jenkins-bot:

[operations/mediawiki-config@master] wgCrossSiteAJAXdomains: Add foundationwiki and {ee,ge,punjabi}wikimedia

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

In T300978#7690415, @Stang wrote:

Tested with x-wikimedia-debug extension, and the problem still exist.

So that's a report-only CSP violation - separate from the CORS issue this bug was attempting to address. Since it's report-only, it should not be blocking the usage of the script, just reporting that it would if CSP were enforcing, which it is not in Wikimedia production at this time. Even if CSP does eventually enforce in Wikimedia production, there would likely be an allow list option for individual users to consent to loading resources from toolforge, wmcs, etc. (see also some discussion here: T239077).

Note: the previous patch was reverted here, though I'm not sure it needed to be: https://gerrit.wikimedia.org/r/q/Ib6576611543b91fe49b8f749a2c21d7c1b5399c7

I decide to un-revert that patch, as it at least partially fixed this issue. Another popular userscript encountered the same issue.

I'd like a member from the secteam to review my original patch again per suggestion from SWAT. In previous deployments I've observed that some of the affected user scripts work fine on all four sites, but some scripts still have some issues (i.e. ajax sysop mentioned in the description).

For CSP violation issue: the [ReportOnly] message is defined in $wgCentralNoticeContentSecurityPolicy, but seems importing a script has no relation with CentralNotice extension?

@Stang - Your un-revert of the original patch on this task would indeed fix the issue mentioned on the meta page for Twinkle that you referenced above. So +1 from the Security-Team for that specific issue. Per the mw manual, that's what a domain being included within $wgCrossSiteAJAXdomains does - allows it to be set as an Origin value for a CORS request.

For the separate CSP issue, $wgCentralNoticeContentSecurityPolicy controls a very specific enforcing CSP for one feature of CentralNotice - its banner preview functionality. This is to protect central notice admins from potentially malicious external resources and scripts. But this isn't MediaWiki's primary CSP functionality. That would largely be the code merged here and controlled mostly by this config. And then foundationwiki has its own separate report-only override. But the important thing to know about CSP is that aside from CentralNotice's banner preview feature, it should only be enabled in report-only mode across other production wikis, if it's even enabled at all. Unlike the aforementioned CORS issue on foundationwiki, CSP's report-only mode should not break or inhibit any external resources, but rather throw various warning messages within developer consoles, etc.

Mentioned in SAL (#wikimedia-operations) [2022-03-22T07:17:47Z] <urbanecm@deploy1002> Synchronized wmf-config/CommonSettings.php: caad5a4df35c0daa5fd3423e4abf5aa4d5c38a7a: wgCrossSiteAJAXdomains: Add foundationwiki and {ee,ge,punjabi}wikimedia (T300978) (duration: 00m 49s)