Since quite some time Jenkins enforces a strict content security policy on HTML files generated by build jobs. The page https://wiki.jenkins.io/display/JENKINS/Configuring+Content+Security+Policy explains the reasons behind and available ways to configure a different setting, mainly through the setting of a JVM argument that has to be added to the Jenkins command line.

Now, the issue with this is that this JVM argument naturally contains spaces, because this is what the CSP standard dictates, and the command line parser seems to be buggy to interpret JVM arguments that contain spaces within it when given via a shell variable (related: http://mail.openjdk.java.net/pipermail/jmh-dev/2015-March/001768.html).

Consider the following trivial example:

Test.java

public class Test {
	public static void main(String[] args) {
		System.out.println(System.getProperty("foo.bar"));
	}
}

test.sh

#!/bin/sh

args="-Dfoo.bar=\"bla foo\""

exec java $args Test

This won't work but output

error: Could not find or load main class foo"

while executing it directly works:

$ java -Dfoo.bar="bla foo" Test
bla foo

Notice how all of the following also do not work and fail:

• args='-Dfoo.bar="bla foo"'
• args="-Dfoo.bar='bla foo'"
• args='-Dfoo.bar=\'bla foo\''
• args='-Dfoo.bar=bla\ foo'
• args="\"-Dfoo.bar=bla foo\""

Since Jenkins instances are mainly executed indirectly from shell scripts, this seems to be a bummer, since there is no obvious way to send that CSP configuration into Jenkins. Maybe there is a total obscure way of doing it, but it's not obvious for somebody with only basic shell fu knowledge like me, so

tl;dr

I wish the CSP configuration (and possibly other related configurations) could simply be done from within the Jenkins UI and be persisted there. If then somehow magically a command line argument pops up for the same setting, it could easily override the setting saved persistently through the UI, but this should really be made easier.