Fwd: Re: [rfc][icedtea-web] reproducer for PR905

[Deepak Bhole]

* Danesh Dadachanji <ddadacha at redhat.com> [2012-04-04 11:40]:
> Adding CCs.
> 
> Cheers,
> Danesh
> 
> On 04/04/12 10:42 AM, Jiri Vanek wrote:
> >uups. Looks Like I have forgot to cc distro-pkg. Please reply to this one.
> >
> >-------- Original Message --------
> >Subject: Re: [rfc][icedtea-web] reproducer for PR905
> >Date: Wed, 04 Apr 2012 15:39:34 +0200
> >From: Jiri Vanek <jvanek at redhat.com>
> >To: Danesh Dadachanji <ddadacha at redhat.com>, Pavel Tisnovsky <ptisnovs at redhat.com>
> >
> >On 04/03/2012 11:48 PM, Danesh Dadachanji wrote:
> >
> >I have cc also Pavel and Omair because -XtrustAll for applets done wrong can be quite serious.
> >
> >>Hi Jiri,
> >>
> >>On 26/03/12 12:55 PM, Jiri Vanek wrote:
> >>>Hi all!
> >>>
> >>>This reproducer is representing pr905 behaviour. All the tests except
> >>>signed jar with parametrised archive are passing, which is correct, and
> >>>the failing test is representing the issue.
> >>>
> >>
> >>Great job, thanks a lot for doing this! Please see comments below.
> >>
> >>>However there is issue which make this reproducer ... useless. All the
> >>>passing ones are nice, and we can include them (if you agree), but the
> >>>falling one is signed applet (and simple signed applet test too) in
> >>>browser. That means that user have to click on "trust" button :-/
> >>>
> >>>And I have currently no idea how to forward to plugin something like
> >>>-Xtrustall :-/
> >>>
> >>>My only idea until now is some environment variable which will plugin
> >>>forward to netx like Xtrustall. However - I have very strong feelings
> >>>that this can be bloody security hole.
> >>
> >>That definitely sounds like a bad security flaw. We need to setup something that user chooses to
> >>flag at runtime themselves (each time possibly), similarly to explicitly passing -Xtrustall to
> >>javaws. However, I'm not sure of any way that can do this securely. =(
> >>
> >>One option off the top of my head, _just for testing_, might be to have a custom build flag for
> >This will be probably the only way. But I dont like it:(
> >I like also the way via itweb-settings, especially when it will be possible via commandline, but it
> >looks wrong in same way as environment variable.
> >>icedtea-web. If we pass it in when building (something like --build-for-testing), it could patch
> >>some of the code to skip the security checks? I'm not sure how suitable this would be though because
> >>it is modifying the code, no matter how small the modification is. =)
> >>
> >>>(definietly is in windows, where you can use activeX to inject
> >>>environment variable imho)
> >>>
> >>>So what do you think about the reproducer. Have it sense to push it
> >>>without signed-applet-in-browser tests?
> >>>
> >>
> >>Firstly, I don't think this test should be pushed until the fix to PR905 is going into HEAD. I don't
> >IMHO failing tests representing issue SHOULD be pushed. Omair have temporarily suspended his effort
> >to ignore failing tests.
> >>really see why having it in before hand is useful considering the issue is happening regardless, it
> >>may also scare off devs from running tests even more. =( Would you prefer to have it in before hand?
> >Definitely O:)
> >But there is the issue with necessary click right now:-/
> >Without signed-parametrized applet they have just small reason.
> >I'm for:
> >to push the parts which are passing
> >to push the signed applet
> >to push failing test
> >BUT to disable last two which are failing due to necessary click:(
> >>
> >>Secondly, regarding the applet-in-browser tests, I think we should keep them there but disable them
> >>until they can actually pass. Let's try to follow what was discussed in this email[1]. See my
> >>comments on AppletTestSigned below, they are similar.
> >>
> >>>For future - any ideas how to create automated tests for signed applets
> >>>in browser? (without awt robot)
> >>>
> >>
> >>Another idea could be to store some option (securely) accessible via itweb-settings..something like
> >>a checkbox for "Trust all applets run in the plugin" and then set this up properly on the test
> >>machine. I am again unclear as to how we would do this in a way that prevents outsiders from
> >>modifying the file that stores this flag on the FS. Do you know of any way in which we could save
> >hmm... some file which can just root modify, and to read it for -XtrustAll? hmm.. this can work!
> >I believe this setting should be held out of itweb-settings.. What about ~/.icedtea ? But probably
> >some location where just root can write will be better. As this is intended just for testing
> >reasons, I'm for direct /etc.
> >>this "setting"? This does go against what I said above where this should be something specified at
> >>runtime of each applet but just throwing it out there. =) I suppose figuring this out would help us
> >>set something similar like an environment variable too though...
> >>
> >>Some more comments in-line.
> >>
> >>> +2012-03-26 Jiri Vanek<jvanek at redhat.com>
> >>
> >>2 spaces between Last name and <email> please.
> >>
> >>> +
> >>> + Added tests for PR905 - parameters in jnlp/html application/applet resources
> >>> + * tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.html:
> >>> + html file for lunching signed applet
> >>> + * tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.jnlp:
> >>> + jnlp fiel for lunched signed applet
> >>
> >>s/fiel/file
> >O:)
> >>
> >>> + * tests/jnlp_tests/signed/AppletTestSigned/srcs/AppletTestSigned.java
> >>> + body of signed applet
> >>> + * tests/jnlp_tests/signed/AppletTestSigned/testcases/AppletTestSignedTests.java:
> >>> + (AppletTestSignedTest) testing method to launch signed applet in javaws
> >>> + (AppletTestSignedFirefoxTest) testing method to launch signed applet in
> >>> + browser
> >>
> >>I think this can be a separate changeset that can be pushed. Just handle the one that is meant to
> >>fail appropriately. I think the resolution from the email thread[1] was to disable them and make
> >>bugs for them (for now at least). Could you go through the changes mentioned below that affect
> >>AppletTestSigned and post a separate review please? Thanks!
> >
> >Yes (definitely :) ). But have no sense unless signed applets can be run automaticaly or as I told
> >above.
> >>


How about creating a cert, importing it and then signing everything with that
cert?

Cheers,
Deepak