Hi Infrastructure experts,
The Derby project uses Jenkins to build the latest version of our user
documentation. The resulting documents are linked from the Derby website
here: http://db.apache.org/derby/manuals/index.html#latest. Some of the
Jenkins-built documentation is in html format and it uses frames. The
Jenkins machines serve up those web pages as blank frames and my Firefox
browser's error console reports the following:
<consoleOutput>
Content Security Policy: Couldn't process unknown directive 'sandbox'
<unknown>
Content Security Policy: The page's settings blocked the loading of a
resource at
https://builds.apache.org/job/Derby-docs/lastSuccessfulBuild/artifact/trunk/out/ref/toc.html
("default-src 'none'").
</consoleOutput>
The frames seem to have been intercepted in order to frustrate a
possible Cross Frame Scripting attack, as described by the default
Jenkins Content Security Policy:
https://wiki.jenkins-ci.org/display/JENKINS/Configuring+Content+Security+Policy#ConfiguringContentSecurityPolicy-Considerations
The default Jenkins Content Security Policy assumes that Apache
continuous-integration builds are exposed to the two risks listed here:
https://wiki.jenkins-ci.org/display/JENKINS/Configuring+Content+Security+Policy#ConfiguringContentSecurityPolicy-Considerations
. I don't believe that Apache's Jenkins builds suffer from the first
risk ("Are less trusted users allowed to create or modify files in
Jenkins workspaces?"). That is because only trusted Apache committers
can trigger Jenkins builds. Do Apache continuous-integration builds
suffer from the second risk ("Are some slaves not fully trusted?").
The Derby developers have begun discussing this problem at
http://apache-database.10148.n7.nabble.com/alpha-docs-not-being-generated-td145918.html
. I would appreciate your advice about how we can stop html frames from
being intercepted and blanked out when readers link to the Jenkins-built
documentation.
Thanks,
-Rick
