db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <rick.hille...@gmail.com>
Subject Re: alpha docs not being generated
Date Sun, 24 Apr 2016 00:32:01 GMT
On 4/23/16 2:04 PM, Kristian Waagan wrote:
> Den 23.04.2016 22.37, skrev Rick Hillegas:
>> On 4/23/16 10:07 AM, Kristian Waagan wrote:
>>> Den 23.04.2016 17.50, skrev Bryan Pendleton:
>>>> On 4/23/2016 7:20 AM, Rick Hillegas wrote:
>>>>> Does anyone know what the problem is?
>>>>>
>>>> No, I'm not sure, sorry.
>>>>
>>>> I can see that Jenkins build #261 was automatically initiated
>>>> after your patch for DERBY-6883 was committed, and the build
>>>> job finished with SUCCESS:
>>>>
>>>>       https://builds.apache.org/job/Derby-docs/261/
>>>>
>>>> And, in the artifacts of the build, I can see your updated docs:
>>>>
>>>>
>>>> https://builds.apache.org/job/Derby-docs/261/artifact/trunk/out/ref/rrefsqlj81859.html
>>>>
>>>>
>>>>
>>>> But the automatic linkage from "lastSuccessfulBuild" to build 261
>>>> doesn't seem to be working, as
>>>>
>>>>
>>>> https://builds.apache.org/job/Derby-docs/lastSuccessfulBuild/artifact/trunk/out/ref/index.html
>>>>
>>>>
>>>>
>>>> is not showing any content for me, it's just a couple top level
>>>> browser frames and a blank screen.
>>>>
>>>> I don't recall any changes to this mechanism recently; is it
>>>> possible that this is a problem on the Jenkins side rather than
>>>> with your commit?
>>> Hi,
>>>
>>> This looks like a problem rooted in CSP (Content Security Policy) -
>>> check your browsers' console.
>>>
>>> I can't tell what has made the problem (which is actually a security
>>> feature :)) manifest, i.e. due to changes in web browsers, or how the
>>> HTTP server is setting the HTTP header. Could potentially even be a
>>> Jenkins update.
>>>
>>> If you must access the site as it is, there are plugins to disable CSP
>>> in the browser(s).
>>>
>>>
>>> Regards,
>> Thanks, Kristian and Bryan. I see the same behavior when using Firefox,
>> Safari, and Chrome. The Firefox error console reports:
>>
>> 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'").
>>
>> That's all Greek to me. Can anyone help parse that output and point a
>> finger at what is broken (or who should be consulted)?
> Based on [1] this looks like a relatively new change in Jenkins.
> Infra may have given this some thought, or Jenkins is simply running
> with the very restrictive defaults.
>
> I believe you have to get the HTTP headers coming from Jenkins modified
> for the current setup to work, and for that you'll need help from
> someone with more karma.
> If the CSP settings in Jenkins can't be changed (technically or
> otherwise), we may have to find another way to host the alpha docs.
>
>
Thanks for that information, Kristian. I think that our use of frames is 
the offending practice which the CSP setting has intercepted. The 
frame-based alpha html docs and public API are both broken. However, the 
alpha pdf manuals still work.

If I understand this correctly, we are at risk only if we meet one of 
the conditions here: 
https://wiki.jenkins-ci.org/display/JENKINS/Configuring+Content+Security+Policy#ConfiguringContentSecurityPolicy-Considerations

. I don't believe that the first condition applies to us ("Are less 
trusted users allowed to create or modify files in Jenkins workspaces?") 
Only trusted committers can trigger Jenkins builds. I don't know enough 
about our Jenkins usage to offer an opinion on the second condition 
("Are some slaves not fully trusted?"). Does anyone know the answer to 
that question?

Thanks,
-Rick

Mime
View raw message