[RFC][icedtea-web] extend reproducers engine for signed applications

[Jiri Vanek]

TYVM for  reply!

On 06/23/2011 03:53 PM, Omair Majid wrote:
> On 06/22/2011 09:08 AM, Jiri Vanek wrote:
>> On 06/21/2011 04:00 PM, Omair Majid wrote:
>>> On 06/21/2011 09:15 AM, Jiri Vanek wrote:
>>>> Hi!
>>>>
>>>> Most of the basic 12 reproducers is throwiing (correct) exception when
>>>> application is not signed. But when it is signed, then they should make
>>>> theirs changes.
>>>
>>> In general, I dont think we _need_ to have a signed application test
>>> for every unsigned application test. Some tests may not make much
>>> sense in a trusted application context. And I dont know if doubling
>>> the number of our tests (assuming we have a signed test for every
>>> unsigned test) is a great idea.
>>>
>>> That said, we certainly will need to add (at least some) signed
>>> application tests - either when bugs are found, or we are implementing
>>> some new features.
>>>
>>>> My ideas was to make duplicatre of each jar fromsimple reproducers and
>>>> sign (self signed - is that enough?) this copy (eg change name of jar to
>>>> "sameAsOriginal-signed.jar" although to reuse jnlp files bounded to this
>>>> jar so they will be named eg sameAsBefore-signed.jnlp and point to
>>>> signed jar. Just testcases will ne necessary to write for signed
>>>> applications again.
>>>> Or to crate directory beside "simple" called "signed" where will be
>>>> sources, resources and testcases for autoamticly compiled and signed
>>>> applets. I would prefere second option, althoug it will leed to small
>>>> duplicate code, it seems clearer to me.
>>>>
>>>
>>> Personally, I prefer the second approach which makes the test
>>> behaviour more explicit. I agree that it keeps things more obvious
>>> (but at the cost of some duplication).
>>>
>>> Cheers,
>>> Omair
>>
>> So I would like to base signing part of reproducers (the rest will be
>> same as current) upon attached script.
>
> So are you doing this for every test?

Not yet:) And not going to. I prefer second approach too. This was just some kind of example of automated signing I'm going to use.

If you remember, we were speaking about simple and advanced directory. Simpel directory is now compiled and jared and deployed automaticaly. signed, will be handled the same way, but at the end it will be also signed - by most simple and i believe most common way - as desgribed in shell script. Also keystore and things around will be  handled like in script.
In advanced directory reproducers must take care about themselves - including they can sign themselves as they like.
>
>> It works fine, except fact that
>> javaws is always asking when unverifiable certificate is delivered.
>> Does exists any mechanism how to force to javaws to trust some
>> certificate? Eg javaws -trusted keyname, or -trustanycoolcert ... As far
>> as I know this is not present in current javaws. Should I add something
>> like that for automated testing purposes?
>
> Yup, seems like a good idea to me. Deepak had asked me to look into something like this, but I never got around to implementing it. May I recommend that you make it a -Xoption? Also, please don't document it in the man page or anywhere else; we would like to avoid users using it (unless they are debugging or something, of course).

Ok. I will work around something like -Xtrustall  option. And continue as described in shell script and aboove (for special set of reproducers and testcases in 'signed' directory.
>
> Cheers,
> Omair

Regards and thanx for your time
J.