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

[Jiri Vanek]

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?

Tahx for check!

J.
>
>
> Regards,
>
>>
>> J.
>>
>