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

[Danesh Dadachanji]

On 04/04/12 11:43 AM, Deepak Bhole wrote:
> * 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?
>

+1, can't believe we didn't think of this before! We don't necessarily need to even create a new cert, the jar's signer is made at 
runtime so all that is needed is adding it to the trusted keystore.

However, since all reproducers are signed by the same cert, that might not be ideal depending on what others are meant to be testing. 
I'm not sure if any use the denial of trust as a test. If so, then another cert would be best.

Cheers,
Danesh