[rfc][icedtea-web] merge property arguments into config singleton (was Re: javaws CLI with Icedtea-web)

Fri Nov 14 14:17:51 UTC 2014

On 11/12/2014 10:46 PM, Jie Kang wrote:
>
>
> ----- Original Message -----
>> On 11/07/2014 04:53 PM, Jie Kang wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> On 10/23/2014 12:55 PM, Jiri Vanek wrote:
>>>>>
>>>>>
>>>>>
>>>>> -------- Forwarded Message --------
>>>>> Subject: Re: javaws CLI with Icedtea-web
>>>>> Date: Tue, 01 Jul 2014 16:57:19 +0200
>>>>> From: Jiri Vanek <jvanek at redhat.com>
>>>>> To: distro-pkg-dev at openjdk.java.net, Omair Majid <omajid at redhat.com>
>>>>>
>>>>> On 07/01/2014 01:32 PM, Jiri Vanek wrote:
>>>>>> On 06/30/2014 05:41 PM, Chris Lee wrote:
>>>>>>> Hi Jacob,
>>>>>>> On Jun 30, 2014, at 5:23 PM, Jacob Wisor wrote:
>>>>>>>
>>>>>>>> On 06/30/2014 04:39 PM, Chris Lee wrote:
>>>>>>>>> Hi Jiri
>>>>>>>>>
>>>>>>>>> Thanks so much
>>>>>>>>>
>>>>>>>>> To explain as well, what I am trying to do is use a specific proxy
>>>>>>>>> server and port for a
>>>>>>>>> specific website.
>>>>>>>>> I had thought that a link to the CLI might be the quickest if I can
>>>>>>>>> get
>>>>>>>>> it working, If there is
>>>>>>>>> an easier way to configure, then I am open to suggestions.
>>>>>>>>
>>>>>>>> Try using Java's network configuration properties like http.proxyHost,
>>>>>>>> http.proxyPort,
>>>>>>>> https.proxyHost, https.proxyPort, ftp.proxyHost, ftp.proxyPort,
>>>>>>>> gopher.proxyHost,
>>>>>>>> gopher.proxyPort, socksProxyHost, socksProxyPort with the -J-D switch.
>>>>>>>> For more information have
>>>>>>>> a look into
>>>>>>>> <JRE_HOME>/lib/net.properties.
>>>>>>> Assuming that they can/should be applied in the same manner as the
>>>>>>> properties from before, but I
>>>>>>> appear to be having the same issue where it is not being applied.
>>>>>>>
>>>>>>> ie:
>>>>>>> [chlee at pc-atlas-cr-35 .icedtea]$ javaws -verbose
>>>>>>> -J-Dhttp.proxy.Host=atlasgw-exp.cern.ch
>>>>>>> -J-Dhttp.proxyPort=3128
>>>>>>> http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp
>>>>>>> Loading User level properties from:
>>>>>>> /atlas-home/1/chlee/.icedtea/deployment.properties
>>>>>>> Starting security dialog thread
>>>>>>> Using firefox's profiles file:
>>>>>>> /atlas-home/1/chlee/.mozilla/firefox/profiles.ini
>>>>>>> Found preferences file:
>>>>>>> /atlas-home/1/chlee/.mozilla/firefox/4mi0hwbe.default/prefs.js
>>>>>>> Read 77 entries from Firefox's preferences
>>>>>>> JNLP file location:
>>>>>>> http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp
>>>>>>> call privileged method: getCodeBase
>>>>>>>            result: null
>>>>>>> Status: CONNECT STARTED +(CONNECT STARTED) @ /dipbrowser/launch.jnlp
>>>>>>> Status: CONNECT DOWNLOAD STARTED +(DOWNLOAD) @ /dipbrowser/launch.jnlp
>>>>>>> Status: CONNECTING DOWNLOAD STARTED +(CONNECTING) -(CONNECT) @
>>>>>>> /dipbrowser/launch.jnlp
>>>>>>> All possible urls for
>>>>>>> location=http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp
>>>>>>> state=CONNECTING DOWNLOAD STARTED :
>>>>>>> [http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp,
>>>>>>> http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp]
>>>>>>> Selecting proxy for:
>>>>>>> http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp
>>>>>>> Browser proxy option "4" (Automatic) not supported yet.
>>>>>>> Browser selected proxies: [DIRECT]
>>>>>>> Selected proxies: [DIRECT]
>>>>>>> Selecting proxy for: socket://dipbrowser.web.cern.ch:80
>>>>>>> Browser proxy option "4" (Automatic) not supported yet.
>>>>>>> Browser selected proxies: [DIRECT]
>>>>>>> Selected proxies: [DIRECT]
>>>>>>>>
>>>>>>>>>> 1.4.1 is outdated. If you need for some reason to stay with 1.4,
>>>>>>>>>> please update to 1.4.2,
>>>>>>>>>> however - please swap to 1.5. It was released few month ago, is
>>>>>>>>>> stable, and a a lot of fixes
>>>>>>>>>> was fixed here.
>>>>>>>>>
>>>>>>>>> This installation is for the ATLAS experiment at CERN. For security
>>>>>>>>> reason, we are usually
>>>>>>>>> compelled to use what is available in the SLC repos, which
>>>>>>>>> unfortunately for me right now is 1.4.1
>>>>>>>>
>>>>>>>> If security is key to you, you shouldn't probably be using IcedTea-Web
>>>>>>>> yet. Instead, resort to
>>>>>>>> Oracle's Java Web Start implementation. This product is feature and
>>>>>>>> specification complete, in
>>>>>>>> contrast to IcedTea-Web. Java Web Start has most probably received far
>>>>>>>> more security fixes and
>>>>>>>> screening than IcedTea-Web. Personally, at the current stage of
>>>>>>>> IcedTea-Web I would advise any
>>>>>>>> enterprise or security aware user not to use IcedTea-Web.
>>>>>>> I believe we had a number of issues with the Oracles Javaws. somethings
>>>>>>> like the latest updates
>>>>>>> forced us to keep things current all the time, and while we are in
>>>>>>> production runs, things can be
>>>>>>> locked down for months at a time or we could lose data taking at our
>>>>>>> experiment.
>>>>>>> Right now this is me testing to see if I can get this to work
>>>>>>>
>>>>>> Chris, Just to completeness, may you try the -Xnofork together with your
>>>>>> Experiments?
>>>>>>
>>>>>> Anyway it sounds like bug. I will look into it.
>>>>>>
>>>>>
>>>>> Well this is  bug. As it is done in ITW, the proxy* settings  are loaded
>>>>> from configurations before
>>>>> the value of -property is  merged.
>>>>>
>>>>> But it do not explain why even the -J-Ddeployment.blah is not working.
>>>>> //me
>>>>> must find what
>>>>> specification says
>>>>>
>>>>> Looking inisde
>>>>>
>>>>> as it was:
>>>>> the ITW properties are loaded form file
>>>>>       + they are mixed into system properties
>>>>> proxy is selected
>>>>> launcher object is created
>>>>> "-property" argument's values  are merged into JNLPresources
>>>>>       and later ... I'mnot sure if they are even later merged into
>>>>>       properties
>>>>>
>>>>> It is clear that original NETX wanted to keep the -property's params as
>>>>> isolated per jnlpfile
>>>>>
>>>>>
>>>>> After attached patch
>>>>> the ITW properties are loaded form file
>>>>>       + they are mixed into system properties
>>>>> "-property" argument's values  are merged  into ITW properties (so not
>>>>> into
>>>>> system properties)
>>>>> proxy is selected
>>>>> launcher object is created
>>>>> "-property" argument's values  are still merged into JNLPresources
>>>>>
>>>>> So now the config singleton have the -property(s) shared. Also set on
>>>>> jnlpconfig value will not
>>>>> change the value in per-jnlpresource
>>>>>
>>>>>
>>>>> I believe that this can be correct as
>>>>>      - javaws have always isolated JVM
>>>>>      - applets, with shared JVM, have always same -property(s) set via
>>>>>      itwsettings (command-line args)
>>>>>
>>>>> Well my fix can probably go into 1.4 and 1.5, but for head the properties
>>>>> should be revisited one
>>>>> more times. Maybe also  -D and -J-D should be handled differently.
>>>>> Are actually -J working with forked JVM? By check on code.. not
>>>>>
>>>>> The patch contains small refactoring to not duplicate code. The test is
>>>>> attached likewise.
>>>>>
>>>>>
>>>>> Chis, are you able to build patched RPMs?
>>>>>
>>>>> J.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ping? Security thoughts?
>>>
>>> Hello,
>>>
>>>
>>> Looking at the code, it seems reasonable. Only nit would be to fix the
>>> typos;;
>>>
>>> In terms of security:
>>>
>>> What this patch does is take user-supplied properties:
>>>
>>> ./javaws -property name=value -jnlp jnlpFile.jnlp
>>>
>>> property: name, value: value and apply them into JNLPRuntime's
>>> configuration, yes? From this view, I don't know if there is a security
>>> issue since it's the user setting the property and not the applet. As long
>>> as applets can't set these properties, it should be okay...
>>
>> Thats quite good and nice point :))
>>>
>>> What kind of things are you worried about? I am no expert here :\
>>
>> I dont know. Unluckily the world of various merged properties is so.. strange
>> that I doubt there is any expert arround :(( Escpecially not me.
>>
>> I have somehow strange feelings about htis changeset. Maybe better palce
>> where to put it? Maybe some security check?
>
> Hello,
>
> I don't have any major issues with this patch. Is there a reproducer/test-case to make sure this fixes the issue that Chris is experiencing?
>
>

Ok. I will push then.

No reprodcuer yet, but should be simple to add. I will work on it... soon.

Once the reproducer is doen, I would like to backpor this also to 1.5.

Actually *this* is 1.5 version patch. For head it have to use new parser...

J.