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

[Omair Majid]

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?

> 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).

Cheers,
Omair