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

[Jie Kang]

----- 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?


Regards,

> 
> Tahx for check!
> 
> J.
> >
> >
> > Regards,
> >
> >>
> >> J.
> >>
> >
> 
> 

-- 

Jie Kang