[RFC][icedtea-web] Use global JarCertVerifier in JNLPClassLoader - tests

[Jiri Vanek]

On 05/17/2012 06:38 PM, Danesh Dadachanji wrote:
> Hi Jiri,
>
...
>>> The nested jar is given the same security context as its parent jar.
>>>
>>
>>
>>> I've extensively tested this against a combination of singed/unsigned entries in
>>
>> Please share those reproducers. They have to be tracked for regression.
>>
>
> Unfortunately all of these are hardcoded jars that I made manually. They're too complicated to add to the test engine. Things like having multiple signers for different jars, having only one of two entries in a jar signed are not possible yet.
>
> I want to avoid pushing jars to the repo. However, I think out of the 50+ scenarios I ran through, there is maybe 10% similarity between all of them, if that even. Each test will need its own mechanism to create proper jars with each test run. We will have to add a new feature to the test engine to do these customized tests.

Yap. I will try to help with it.

>As we discussed on IRC, the best looking approach is to use additional Makefiles in each of the tests' directories. Then, if these are present, the test is built according to this Makefile's specifications. I will have to think about this some more but I'll just leave this here for now. =)

I'm hesitating with delaying the tests. Imho tests are always forgotten when fix is delivered... There is always something more funny to do then tests. I would prefer th etest have priorirty before fix .. at least some most-issue-describing ones.

Do you think you can include few (cca 5) most describing ones (probably with Make extension)?
>
>>> resource/archive-specified/nested/manifest-classpath/extension jars using JNLPs, the applet tag,
>>> javaws and jnlp_href, as well as many duplicate jars. I have also run through all the regression
>>
>> I think this changset do not belongs to 1.1. What is motivation for do so?
>
> This is a very security oriented fix. Right now in 1.1 we do not ensure that the entire app is signed by 1 common signer. If jars are brought in on the fly (e.g. classpath), they currently can have different signers. Technically we are okay for JNLPs because of other restrictions (such as no manifest classpaths accepted) but IMHO that's too close of a call that it's scary. Having this global JCV will ensure that everything absolutely must be signed by at least 1 signer, not just the jars passed in when doing the verification.

Ok. Thanx for clarification.

>
>>
>>> tests for HEAD, 1.2 and 1.1, everything ran fine.
>>>
>>
>>
>>
>> ^ This is true reason of my reply. This changeset will need bunch of reproducers. They will be better even before the push of this
>> changeset so I will be able to track they fix.
>>
>> Sorry for adding more work but it is really necessary.
>
> np =)
>
>>
>> Also when I walked through code of JarCertVerifier, it looks like easily to be tempted by unnit tests. What do you think?
>
> Unit tests are hard for JCV. =( For my major update to JCV (that is still in the works), I focused on making the class more unit testable. Currently, it's very dependent on passing JARDesc lists into the methods. IOW we would have to create these jars inside of the unit tests. That's a whole other task in itself. TBH I think it will be wasted effort to do this if my larger JCV updates will make things easier.

Good!
>
>>
>>
>> Thanx again, J.
>
> Thanks for reviewing!
>
> Cheers,
> Danesh