Which url is this? AFAIK we haven't enabled CSP on doc.wikimedia.org yet (T213223).

So unless unsafe-inline is specified, you can only load CSS via <link> tags.

I believe the primary usecase is in the event of CSS injection to prevent leaking data via unclosed CSS constructs (e.g. https://scarybeastsecurity.blogspot.com/2009/12/generic-cross-browser-cross-domain.html ) and also phising related attacks by restyling the page. Really I don't think these apply very much in the context of doc.wikimedia.org where there is no private data (and we prevent third party loads by other CSP directives)

So i think we should just allow unsafe-inline

These are not documentation pages published to doc.wikimedia.org post-merge (trusted).

Instead, they are HTML artefacts collected by Jenkins from pre-merge code (untrusted), and on integration.wikimedia.org - which has a strict CSP (unlike doc.wikimedia.org).

Example: https://integration.wikimedia.org/ci/job/mediawiki-phpunit-coverage-patch-docker/5086/artifact/log/coverage.html

This domain is definitely sensitive and needs a strict CSP. But, having said that, these untrusted resources are only ever loaded as their own url, not embedded elsewhere. As such, using CSS for styling purposes within these page should be safe indeed.

I'm not sure we should loosen it on the domain generally though, as that would affect Jenkins and Zuul page views as well. The domain path is a bit mixed up, but perhaps we can limit it to /ci/job/*/*/artifact/log/*.html?

Sorry about the domain confusion. It was supposed to be integration.wikimedia.org.

In T215115#4923607, @Krinkle wrote:

Example: https://integration.wikimedia.org/ci/job/mediawiki-phpunit-coverage-patch-docker/5086/artifact/log/coverage.html

For reference, the CSP headers are:

content-security-policy: sandbox; default-src 'none'; img-src 'self'; style-src 'self';
x-webkit-csp: sandbox; default-src 'none'; img-src 'self'; style-src 'self';
x-content-security-policy: sandbox; default-src 'none'; img-src 'self'; style-src 'self';

We had CSP issues on T155794 (declined). Jenkins LTS 1.625.3 introduced the CSP, the documentation being at https://wiki.jenkins.io/display/JENKINS/Configuring+Content+Security+Policy . According to that documentation the default rule is:

sandbox; default-src 'none'; img-src 'self'; style-src 'self';

This rule set results in the following:

No JavaScript allowed at all
No plugins (object/embed) allowed
No inline CSS, or CSS from other sites allowed
No images from other sites allowed
No frames allowed
No web fonts allowed
No XHR/AJAX allowed
etc.

If we want to adjust it, we need to pass a system property when starting Jenkins (that is done via puppet configuration):

java -Dhudson.model.DirectoryBrowserSupport.CSP= -jar jenkins.war

But I cant tell about the security implications if we change the rules.

I once filled a task upstream to have the artifacts to be served from a different domain (eg: wmfusercontent.org) but I have not acted on that task nor tried to get the feature implemented.

I also had a task to have CI build material to be published outside of Jenkins (eg: Swift T53447 ) and served by wmfusercontent.org. That would probably solves the problem entirely (and let us scale the amount of artifacts we keep).

In T215115#4926869, @hashar wrote:

We had CSP issues on T155794 (declined). Jenkins LTS 1.625.3 introduced the CSP, the documentation being at https://wiki.jenkins.io/display/JENKINS/Configuring+Content+Security+Policy . According to that documentation the default rule is:

sandbox; default-src 'none'; img-src 'self'; style-src 'self';

This rule set results in the following:

No JavaScript allowed at all
No plugins (object/embed) allowed
No inline CSS, or CSS from other sites allowed
No images from other sites allowed
No frames allowed
No web fonts allowed
No XHR/AJAX allowed
etc.

If we want to adjust it, we need to pass a system property when starting Jenkins (that is done via puppet configuration):

java -Dhudson.model.DirectoryBrowserSupport.CSP= -jar jenkins.war

But I cant tell about the security implications if we change the rules.

IMO, Adding 'unsafe-inline' to the style-src directive (And only that directive. It would be bad to add this to script-src or default-src.) is probably pretty safe.

I once filled a task upstream to have the artifacts to be served from a different domain (eg: wmfusercontent.org) but I have not acted on that task nor tried to get the feature implemented.

I also had a task to have CI build material to be published outside of Jenkins (eg: Swift T53447 ) and served by wmfusercontent.org. That would probably solves the problem entirely (and let us scale the amount of artifacts we keep).

And also be better for security (CSP mitigates, but serving untrusted html on a *.wikimedia.org domain is still kinda scary - viz. T113790#1676633)

Change 582604 had a related patch set uploaded (by Brian Wolff; owner: Brian Wolff):
[operations/puppet@production] Adjust CSP to allow inline CSS & playing MP4 videos on jenkins

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

Change 582604 merged by Giuseppe Lavagetto:
[operations/puppet@production] jenkins: Adjust CSP header to allow inline CSS and video playback

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

Change 585035 had a related patch set uploaded (by Hashar; owner: Hashar):
[operations/puppet@production] Revert "jenkins: Adjust CSP header to allow inline CSS and video playback"

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

Change 585035 merged by Cwhite:
[operations/puppet@production] Revert "jenkins: Adjust CSP header to allow inline CSS and video playback"

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

Change 585038 had a related patch set uploaded (by Hashar; owner: Brian Wolff):
[operations/puppet@production] jenkins: Adjust CSP header to allow inline CSS and video playback

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

Change 585038 merged by Jcrespo:
[operations/puppet@production] jenkins: Adjust CSP header to allow inline CSS and video playback

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