I think we'd need to fix T211539: Beta Cluster cross-wiki login request would be blocked by CSP at least, first.

In T244124#5846341, @Jdforrester-WMF wrote:

I think we'd need to fix T211539: Beta Cluster cross-wiki login request would be blocked by CSP at least, first.

Yes definitely

So looking at logstash-beta, the only reports I see for beta wiki, are either blob: webworker stuff (T245981 should already be fixed), or some user scripts loading CVN or intuition from toolforge. However, I'm not 100% sure all events are being logged, as the number of events seem very low. I just tried to manually trigger some errors and they didn't seem to show up on logstash-beta.

Anyways, I would still like to move forward with setting enforce on beta wiki, so we can do better testing of CSP.

So in my testing, current things still being blocked by CSP that shouldn't:

• event-gate.wmflabs.org
• maps-beta.wmflabs.org (Waiting on https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/569520/ )
• [Although i did not trigger it] - maybe sentry-beta.wmflabs.org

Alternatively, we could give up on the idea of dependencies being responsible for adding services they use to the CSP url, and instead just whitelist *.wmflabs.org as an analog to *.wikimedia.org in production.

ok, so i now have logging on beta cluster. https://logstash-beta.wmflabs.org/goto/c52efa2d6f716c7c61d96f394ea3e34a is the report of current CSP violations

So, ignoring sentry for the moment, the only reports there are for various javascript and css customizations from gadgets and MediaWiki:Common.js [especially on beta commons]. loading scripts from prod. So that's generally good and is as expected.

The question still remains, do we want beta cluster isolated from prod, with the CSP policy blocking loading stuff from prod, or do we consider loading stuff from prod on beta to be normal, and allow it on beta?

Last of all, there are lots of reports on zh.wikipedia.beta.wmflabs.org of Gadget-Wikiplus.js, which would very intentionally be blocked

One thing that does come up on the CSP reports for beta cluster is https://en.wikiversity.org/w/index.php?title=Special:HideBanners&duration=604800&category=CNbrowsertests&reason=close (And similar for other wikis). One would assume CentralNotice should be hitting the equivalent on beta, not production's close all banners.

The question still remains, do we want beta cluster isolated from prod, with the CSP policy blocking loading stuff from prod, or do we consider loading stuff from prod on beta to be normal, and allow it on beta?

On reflection, i think we should allow prod access from beta cluster. Users like to test their user-scripts there, and it seems like a reasonable use-case.

Change 579890 had a related patch set uploaded (by Brian Wolff; owner: Brian Wolff):
[operations/mediawiki-config@master] Make CSP enforce on beta

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

Change 579890 merged by jenkins-bot:
[operations/mediawiki-config@master] Make CSP enforce on beta

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

Mentioned in SAL (#wikimedia-operations) [2020-03-16T16:48:42Z] <jforrester@deploy1001> Synchronized wmf-config/InitialiseSettings.php: Set wmgUseCSP false everywhere T244124 (duration: 01m 07s)

Mentioned in SAL (#wikimedia-operations) [2020-03-16T16:52:47Z] <jforrester@deploy1001> Synchronized wmf-config/CommonSettings.php: Enforce Content Security Policy if wmgUseCSP is set T244124 (duration: 01m 06s)

Ok, so looking at the results, it seems like the only thing that is generating reports (that is unexpected) are:

• http://eventgate-logging.wmflabs.org/v1/events?hasty=true <-- Being blocked because http and not https. I guess this is coming from sentry somehow (T248274)
• https://maps-beta.wmflabs.org/ - but only on wikidata. Looks like the custom header isn't being sent when loaded by wikidata. This is because CachingKartographerEmbeddingHandler kind of redoes a lot of the Kartographer logic (T248278)

In T244124#5990643, @Bawolff wrote:

Ok, so looking at the results, it seems like the only thing that is generating reports (that is unexpected) are:

• http://eventgate-logging.wmflabs.org/v1/events?hasty=true <-- Being blocked because http and not https. I guess this is coming from sentry somehow

Isn't eventgate some analytics thing? In any case that runs through the usual labs web proxy so should be able to do HTTPS just fine. We probably just need to fix a URL in some config somewhere.

In T244124#5990645, @Krenair wrote:

In T244124#5990643, @Bawolff wrote:

Ok, so looking at the results, it seems like the only thing that is generating reports (that is unexpected) are:

• http://eventgate-logging.wmflabs.org/v1/events?hasty=true <-- Being blocked because http and not https. I guess this is coming from sentry somehow

Isn't eventgate some analytics thing? In any case that runs through the usual labs web proxy so should be able to do HTTPS just fine. We probably just need to fix a URL in some config somewhere.

Yes, I think it even uses https some of the time. It seems to be part of Sentry. The config variables do use https. So IDK

In T244124#5990664, @Bawolff wrote:

In T244124#5990645, @Krenair wrote:

In T244124#5990643, @Bawolff wrote:

Ok, so looking at the results, it seems like the only thing that is generating reports (that is unexpected) are:

• http://eventgate-logging.wmflabs.org/v1/events?hasty=true <-- Being blocked because http and not https. I guess this is coming from sentry somehow

Isn't eventgate some analytics thing? In any case that runs through the usual labs web proxy so should be able to do HTTPS just fine. We probably just need to fix a URL in some config somewhere.

Yes, I think it even uses https some of the time. It seems to be part of Sentry. The config variables do use https. So IDK

Okay. Possibly wgWMEClientErrorIntakeURL in wmf-config/InitialiseSettings-labs.php?

Ok, one additional report in the logs of m.wikidata.beta.wmflabs.org being blocked.

https://gerrit.wikimedia.org/r/#/c/operations/mediawiki-config/+/582633

https://commons.wikimedia.beta.wmflabs.org/wiki/Special:UploadWizard

Content Security Policy: The page’s settings blocked the loading of a resource at https://api.flickr.com/services/rest/?&api_key=e9d…=json&nojsoncallback=1&method=flickr.photos.licenses.getInfo (“default-src”).

In T244124#5952902, @Bawolff wrote:

Last of all, there are lots of reports on zh.wikipedia.beta.wmflabs.org of Gadget-Wikiplus.js, which would very intentionally be blocked

@zhuyifei1999 @King_of_Hearts @VIGNERON @mys_721tx @Jianhui67 I don't know what Wikiplus is.